From owner-freebsd-security Sun Aug 5 11:58:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id 56CE037B401 for ; Sun, 5 Aug 2001 11:58:19 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 6690F1E005 for ; Sun, 5 Aug 2001 14:58:10 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA18768 for ; Sun, 5 Aug 2001 14:58:05 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA15976; Sun, 5 Aug 2001 11:58:04 -0700 (PDT) Message-Id: <200108051858.LAA15976@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: freebsd-security@freebsd.org Subject: Opie and protecting passphrases Date: Sun, 5 Aug 2001 11:58:03 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b 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'd like to start a discussion on the subject of protecting passphrases. Opie tries really hard to protect the user from typing their passphrase over an insecure connection; any time you run programs like opiekey or opiepasswd they say: Reminder: Don't use opiekey from telnet or dial-in sessions. If they think that you are not using a secure session, they say: Sorry, but you don't seem to be on the console or a secure terminal. and do not prompt for the pass phrase. There is an "-f" flag to override this check, but it's not enabled by the FreeBSD build: nectar% otp-md5 -f 1 nanny Sorry, but the -f option is not supported by this build of OPIE. I'd like to enable opie's "INSECURE_OVERRIDE" by default in FreeBSD. My reasoning is that: a) opie uses heuristics, which can't always be right. b) The heuristics can be fooled, so they are not a panacea even if they're usually right. c) the default behavior continues to be that the user is not prompted for the passphrase; INSECURE_OVERRIDE only allows specifying the "-f" flag. d) Other parts of the system, like ssh, make no attempt to protect the user from typing a passphrase over an insecure connection. See PR bin/23203: http://www.freebsd.org/cgi/query-pr.cgi?pr=23203 for more details. Thanks for any thoughts, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Aug 5 13:20:43 2001 Delivered-To: freebsd-security@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id A9F1437B401 for ; Sun, 5 Aug 2001 13:20:39 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.4/8.11.4) id f75KI8f47559; Mon, 6 Aug 2001 00:18:08 +0400 (MSD) (envelope-from ache) Date: Mon, 6 Aug 2001 00:18:07 +0400 From: "Andrey A. Chernov" To: Bill Fenner Cc: freebsd-security@FreeBSD.ORG Subject: Re: Opie and protecting passphrases Message-ID: <20010806001807.A47300@nagual.pp.ru> References: <200108051858.LAA15976@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200108051858.LAA15976@windsor.research.att.com> User-Agent: Mutt/1.3.19i 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 Sun, Aug 05, 2001 at 11:58:03 -0700, Bill Fenner wrote: > > I'd like to enable opie's "INSECURE_OVERRIDE" by default in FreeBSD. I too. We can add just opposite option for admins which don't trust any remote connection. Since nowdays most machines are servers with even no regular console access, remote OPIE usage should be preferred and default. > My reasoning is that: > a) opie uses heuristics, which can't always be right. Moreover, this heuristics not covers many secure connection schemes like SSH, SRA Telnet, Kerberos, etc. It means that current OPIE effectively prevents user to use secure connection in regular way. F.e. if his password count goes to zero, with current variant he must ask sysadmin each time to change it since opiepasswd don't know anything about his secure connection and refuses to run. Even running OPIE on console currently have problems too, because you can't use things like 'screen'. > b) The heuristics can be fooled, so they are not a panacea even if they're > usually right. Yes. F.e. for opiekey -f restriction leads to re-compiled (-f enabled) unofficial opiekey distribution from users community (since opiekey don't use s-bit and protected files, it is just calculator). > d) Other parts of the system, like ssh, make no attempt to protect the > user from typing a passphrase over an insecure connection. Moreover, previous SKEY library which OPIE tries to replace now have all this things enabled, so we need to enable them for compatibility reasons too. I want to add a word about /etc/opieaccess too which is replacement for former /etc/skey.access and contains trusted network numbers. This file parsing must be enabled (compiled in) by default too for compatiility reasons and various purposes like FTP tunneling via SSH (on single machine without any trusted networks). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Aug 5 13:31:56 2001 Delivered-To: freebsd-security@freebsd.org Received: from emout1.wish.nl (emout1.wish.nl [212.123.129.74]) by hub.freebsd.org (Postfix) with ESMTP id A417C37B401 for ; Sun, 5 Aug 2001 13:31:50 -0700 (PDT) (envelope-from abgoeree@wish.net) Received: from mail3.inside.servers (mail3.INSIDE.servers [10.1.0.7]) by emout1.wish.nl (Postfix) with SMTP id 45C9121861 for ; Sun, 5 Aug 2001 22:48:39 +0200 (CEST) Received: (qmail 42633 invoked from network); 5 Aug 2001 20:31:47 -0000 Received: from p12870.nl.wish.net (HELO ) ([212.123.188.70]) (envelope-sender ) by mail3.outside.servers (qmail-ldap-1.03) with SMTP for ; 5 Aug 2001 20:31:47 -0000 Received: (qmail 5078 invoked by uid 1000); 5 Aug 2001 20:31:27 -0000 From: "Andre Goeree" Date: Sun, 5 Aug 2001 22:31:27 +0200 To: security@freebsd.org Subject: multiple port scans: tcp/8888 Message-ID: <20010805223127.A4779@mandark.attica.home> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Sender: abgoeree@wish.net 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 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello -security, Attached is part of my ipfilter log. The file shows port scans coming in from 25 different IP addresses from all over the world (Europe, USA, Asia) to tcp/8888. Since I could not find any information about tcp/8888, any comments are appreciated. Ago. --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipf.log" Jul 30 19:36:21 mandark ipmon[105]: 19:36:21.547418 tun0 @100:14 b 193.159.130.183,2029 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN Jul 30 19:36:22 mandark ipmon[105]: 19:36:22.467461 tun0 @100:14 b 193.159.130.183,2029 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN Jul 30 19:36:23 mandark ipmon[105]: 19:36:23.237444 tun0 @100:14 b 193.159.130.183,2029 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN Jul 30 19:36:25 mandark ipmon[105]: 19:36:25.077470 tun0 @100:14 b 193.159.130.183,2029 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN Jul 30 19:36:28 mandark ipmon[105]: 19:36:27.977529 2x tun0 @100:14 b 166.90.42.99,1397 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:36:30 mandark ipmon[105]: 19:36:30.087509 tun0 @100:14 b 166.90.42.99,1397 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:37:31 mandark ipmon[105]: 19:37:31.208244 tun0 @100:14 b 65.67.60.40,1845 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:37:32 mandark ipmon[105]: 19:37:31.878241 tun0 @100:14 b 65.67.60.40,1845 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:37:33 mandark ipmon[105]: 19:37:32.578264 2x tun0 @100:14 b 65.67.60.40,1845 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:37:41 mandark ipmon[105]: 19:37:41.378411 tun0 @100:14 b 216.143.213.49,3508 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:37:42 mandark ipmon[105]: 19:37:42.198400 tun0 @100:14 b 216.143.213.49,3508 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:37:43 mandark ipmon[105]: 19:37:42.998416 tun0 @100:14 b 216.143.213.49,3508 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:37:54 mandark ipmon[105]: 19:37:54.308570 tun0 @100:14 b 151.28.3.209,1442 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:37:56 mandark ipmon[105]: 19:37:55.848541 tun0 @100:14 b 151.28.3.209,1442 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:37:57 mandark ipmon[105]: 19:37:57.448526 tun0 @100:14 b 151.28.3.209,1442 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:38:09 mandark ipmon[105]: 19:38:09.508725 tun0 @100:14 b 213.132.137.155,1641 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:38:10 mandark ipmon[105]: 19:38:10.528706 tun0 @100:14 b 213.132.137.155,1641 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:00 mandark ipmon[105]: 19:38:59.459266 2x tun0 @100:14 b 217.80.71.22,3190 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:21 mandark ipmon[105]: 19:39:21.409528 tun0 @100:14 b 151.20.116.123,1583 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:22 mandark ipmon[105]: 19:39:22.099650 tun0 @100:14 b 151.20.116.123,1583 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:23 mandark ipmon[105]: 19:39:22.691221 2x tun0 @100:14 b 151.20.116.123,1583 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:24 mandark ipmon[105]: 19:39:23.801282 tun0 @100:14 b 172.190.193.75,3370 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:24 mandark ipmon[105]: 19:39:24.029562 tun0 @100:14 b 213.4.32.163,1642 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:25 mandark ipmon[105]: 19:39:25.159760 tun0 @100:14 b 172.190.193.75,3370 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:26 mandark ipmon[105]: 19:39:26.561214 tun0 @100:14 b 172.190.193.75,3370 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:27 mandark ipmon[105]: 19:39:27.619666 tun0 @100:14 b 217.229.204.92,2203 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:28 mandark ipmon[105]: 19:39:27.929757 tun0 @100:14 b 172.190.193.75,3370 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:28 mandark ipmon[105]: 19:39:28.301235 tun0 @100:14 b 217.229.204.92,2203 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:29 mandark ipmon[105]: 19:39:28.929662 2x tun0 @100:14 b 217.229.204.92,2203 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:32 mandark ipmon[105]: 19:39:32.609767 tun0 @100:14 b 213.4.32.163,1642 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:39:44 mandark ipmon[105]: 19:39:44.859937 tun0 @100:14 b 193.159.130.183,2549 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN Jul 30 19:39:45 mandark ipmon[105]: 19:39:45.669844 tun0 @100:14 b 193.159.130.183,2549 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN Jul 30 19:39:46 mandark ipmon[105]: 19:39:46.469816 tun0 @100:14 b 193.159.130.183,2549 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN Jul 30 19:39:47 mandark ipmon[105]: 19:39:47.510327 tun0 @100:14 b 193.159.130.183,2549 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN Jul 30 19:40:10 mandark ipmon[105]: 19:40:09.360151 tun0 @100:14 b 64.240.35.79,1917 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:40:11 mandark ipmon[105]: 19:40:10.561723 tun0 @100:14 b 64.240.35.79,1917 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:40:12 mandark ipmon[105]: 19:40:11.401828 tun0 @100:14 b 64.240.35.79,1917 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:40:24 mandark ipmon[105]: 19:40:23.850328 tun0 @100:14 b 151.21.99.66,3741 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:40:25 mandark ipmon[105]: 19:40:25.030379 tun0 @100:14 b 151.21.99.66,3741 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:40:27 mandark ipmon[105]: 19:40:26.430331 2x tun0 @100:14 b 151.21.99.66,3741 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:40:32 mandark ipmon[105]: 19:40:31.400442 2x tun0 @100:14 b 24.100.126.202,64457 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:40:35 mandark ipmon[105]: 19:40:35.020406 tun0 @100:14 b 24.100.126.202,64457 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:40:45 mandark ipmon[105]: 19:40:44.510514 2x tun0 @100:14 b 62.226.215.79,61316 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:40:45 mandark ipmon[105]: 19:40:45.130497 tun0 @100:14 b 216.72.52.94,1237 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:40:46 mandark ipmon[105]: 19:40:45.710532 2x tun0 @100:14 b 62.226.215.79,61316 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:40:47 mandark ipmon[105]: 19:40:47.440525 tun0 @100:14 b 216.72.52.94,1237 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:40:49 mandark ipmon[105]: 19:40:49.150630 tun0 @100:14 b 216.72.52.94,1237 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:41:26 mandark ipmon[105]: 19:41:26.141790 2x tun0 @100:14 b 24.229.86.45,4371 -> 212.123.189.17,8888 PR tcp len 20 64 -S IN Jul 30 19:41:27 mandark ipmon[105]: 19:41:27.570976 tun0 @100:14 b 24.229.86.45,4371 -> 212.123.189.17,8888 PR tcp len 20 64 -S IN Jul 30 19:41:28 mandark ipmon[105]: 19:41:28.280999 tun0 @100:14 b 24.229.86.45,4371 -> 212.123.189.17,8888 PR tcp len 20 64 -S IN Jul 30 19:41:34 mandark ipmon[105]: 19:41:34.171088 2x tun0 @100:14 b 24.14.143.86,2054 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:41:35 mandark ipmon[105]: 19:41:35.521100 tun0 @100:14 b 24.14.143.86,2054 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:41:36 mandark ipmon[105]: 19:41:36.211107 tun0 @100:14 b 24.14.143.86,2054 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:41:39 mandark ipmon[105]: 19:41:38.041146 2x tun0 @100:14 b 62.136.26.149,1174 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:41:40 mandark ipmon[105]: 19:41:39.511138 tun0 @100:14 b 62.136.26.149,1174 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:41:46 mandark ipmon[105]: 19:41:45.931197 tun0 @100:14 b 213.217.170.230,1609 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:41:48 mandark ipmon[105]: 19:41:47.471238 tun0 @100:14 b 213.217.170.230,1609 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:41:50 mandark ipmon[105]: 19:41:49.171253 tun0 @100:14 b 213.217.170.230,1609 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:41:59 mandark ipmon[105]: 19:41:58.981382 tun0 @100:14 b 62.0.77.112,1687 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:42:01 mandark ipmon[105]: 19:42:00.671363 tun0 @100:14 b 62.0.77.112,1687 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:42:02 mandark ipmon[105]: 19:42:01.911390 tun0 @100:14 b 62.0.77.112,1687 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:42:02 mandark ipmon[105]: 19:42:02.011375 tun0 @100:14 b 63.42.158.65,3095 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:42:08 mandark ipmon[105]: 19:42:07.331469 2x tun0 @100:14 b 62.31.37.87,2375 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:42:09 mandark ipmon[105]: 19:42:08.561437 2x tun0 @100:14 b 62.31.37.87,2375 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:42:16 mandark ipmon[105]: 19:42:16.153864 tun0 @100:14 b 66.56.121.127,1950 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:42:17 mandark ipmon[105]: 19:42:17.201565 tun0 @100:14 b 66.56.121.127,1950 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN Jul 30 19:42:18 mandark ipmon[105]: 19:42:17.904583 tun0 @100:14 b 66.56.121.127,1950 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN --FL5UXtIhxfXey3p5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Aug 5 13:57:58 2001 Delivered-To: freebsd-security@freebsd.org Received: from kahlan.lethal.dk (unknown [62.242.235.180]) by hub.freebsd.org (Postfix) with SMTP id D9BC037B401 for ; Sun, 5 Aug 2001 13:57:53 -0700 (PDT) (envelope-from maj@kahlan.lethal.dk) Received: (qmail 10905 invoked by uid 1000); 5 Aug 2001 20:57:49 -0000 Date: Sun, 5 Aug 2001 22:57:49 +0200 From: Morten Aaboe To: security@freebsd.org Subject: Re: multiple port scans: tcp/8888 Message-ID: <20010805225749.A26335@kahlan.lethal.dk> References: <20010805223127.A4779@mandark.attica.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010805223127.A4779@mandark.attica.home>; from abgoeree@wish.net on Sun, Aug 05, 2001 at 10:31:27PM +0200 X-GPG-Fingerprint: A0A0 06D7 C897 30EC 0BB6 54D3 473C 3C5F 388C 02E6 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 ddi-tcp-1 8888/tcp NewsEDGE server TCP (TCP 1) ddi-udp-1 8888/udp NewsEDGE server UDP (UDP 1) -- M. Aaboe On Sun, Aug 05, 2001 at 10:31:27PM +0200, Andre Goeree wrote: > Hello -security, > > Attached is part of my ipfilter log. The file shows port scans coming > in from 25 different IP addresses from all over the world (Europe, > USA, Asia) to tcp/8888. Since I could not find any information about > tcp/8888, any comments are appreciated. > > Ago. > Jul 30 19:36:21 mandark ipmon[105]: 19:36:21.547418 tun0 @100:14 b 193.159.130.183,2029 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN > Jul 30 19:36:22 mandark ipmon[105]: 19:36:22.467461 tun0 @100:14 b 193.159.130.183,2029 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN > Jul 30 19:36:23 mandark ipmon[105]: 19:36:23.237444 tun0 @100:14 b 193.159.130.183,2029 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN > Jul 30 19:36:25 mandark ipmon[105]: 19:36:25.077470 tun0 @100:14 b 193.159.130.183,2029 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN > Jul 30 19:36:28 mandark ipmon[105]: 19:36:27.977529 2x tun0 @100:14 b 166.90.42.99,1397 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:36:30 mandark ipmon[105]: 19:36:30.087509 tun0 @100:14 b 166.90.42.99,1397 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:37:31 mandark ipmon[105]: 19:37:31.208244 tun0 @100:14 b 65.67.60.40,1845 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:37:32 mandark ipmon[105]: 19:37:31.878241 tun0 @100:14 b 65.67.60.40,1845 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:37:33 mandark ipmon[105]: 19:37:32.578264 2x tun0 @100:14 b 65.67.60.40,1845 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:37:41 mandark ipmon[105]: 19:37:41.378411 tun0 @100:14 b 216.143.213.49,3508 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:37:42 mandark ipmon[105]: 19:37:42.198400 tun0 @100:14 b 216.143.213.49,3508 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:37:43 mandark ipmon[105]: 19:37:42.998416 tun0 @100:14 b 216.143.213.49,3508 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:37:54 mandark ipmon[105]: 19:37:54.308570 tun0 @100:14 b 151.28.3.209,1442 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:37:56 mandark ipmon[105]: 19:37:55.848541 tun0 @100:14 b 151.28.3.209,1442 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:37:57 mandark ipmon[105]: 19:37:57.448526 tun0 @100:14 b 151.28.3.209,1442 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:38:09 mandark ipmon[105]: 19:38:09.508725 tun0 @100:14 b 213.132.137.155,1641 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:38:10 mandark ipmon[105]: 19:38:10.528706 tun0 @100:14 b 213.132.137.155,1641 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:00 mandark ipmon[105]: 19:38:59.459266 2x tun0 @100:14 b 217.80.71.22,3190 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:21 mandark ipmon[105]: 19:39:21.409528 tun0 @100:14 b 151.20.116.123,1583 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:22 mandark ipmon[105]: 19:39:22.099650 tun0 @100:14 b 151.20.116.123,1583 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:23 mandark ipmon[105]: 19:39:22.691221 2x tun0 @100:14 b 151.20.116.123,1583 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:24 mandark ipmon[105]: 19:39:23.801282 tun0 @100:14 b 172.190.193.75,3370 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:24 mandark ipmon[105]: 19:39:24.029562 tun0 @100:14 b 213.4.32.163,1642 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:25 mandark ipmon[105]: 19:39:25.159760 tun0 @100:14 b 172.190.193.75,3370 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:26 mandark ipmon[105]: 19:39:26.561214 tun0 @100:14 b 172.190.193.75,3370 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:27 mandark ipmon[105]: 19:39:27.619666 tun0 @100:14 b 217.229.204.92,2203 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:28 mandark ipmon[105]: 19:39:27.929757 tun0 @100:14 b 172.190.193.75,3370 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:28 mandark ipmon[105]: 19:39:28.301235 tun0 @100:14 b 217.229.204.92,2203 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:29 mandark ipmon[105]: 19:39:28.929662 2x tun0 @100:14 b 217.229.204.92,2203 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:32 mandark ipmon[105]: 19:39:32.609767 tun0 @100:14 b 213.4.32.163,1642 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:39:44 mandark ipmon[105]: 19:39:44.859937 tun0 @100:14 b 193.159.130.183,2549 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN > Jul 30 19:39:45 mandark ipmon[105]: 19:39:45.669844 tun0 @100:14 b 193.159.130.183,2549 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN > Jul 30 19:39:46 mandark ipmon[105]: 19:39:46.469816 tun0 @100:14 b 193.159.130.183,2549 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN > Jul 30 19:39:47 mandark ipmon[105]: 19:39:47.510327 tun0 @100:14 b 193.159.130.183,2549 -> 212.123.189.17,8888 PR tcp len 20 44 -S IN > Jul 30 19:40:10 mandark ipmon[105]: 19:40:09.360151 tun0 @100:14 b 64.240.35.79,1917 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:40:11 mandark ipmon[105]: 19:40:10.561723 tun0 @100:14 b 64.240.35.79,1917 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:40:12 mandark ipmon[105]: 19:40:11.401828 tun0 @100:14 b 64.240.35.79,1917 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:40:24 mandark ipmon[105]: 19:40:23.850328 tun0 @100:14 b 151.21.99.66,3741 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:40:25 mandark ipmon[105]: 19:40:25.030379 tun0 @100:14 b 151.21.99.66,3741 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:40:27 mandark ipmon[105]: 19:40:26.430331 2x tun0 @100:14 b 151.21.99.66,3741 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:40:32 mandark ipmon[105]: 19:40:31.400442 2x tun0 @100:14 b 24.100.126.202,64457 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:40:35 mandark ipmon[105]: 19:40:35.020406 tun0 @100:14 b 24.100.126.202,64457 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:40:45 mandark ipmon[105]: 19:40:44.510514 2x tun0 @100:14 b 62.226.215.79,61316 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:40:45 mandark ipmon[105]: 19:40:45.130497 tun0 @100:14 b 216.72.52.94,1237 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:40:46 mandark ipmon[105]: 19:40:45.710532 2x tun0 @100:14 b 62.226.215.79,61316 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:40:47 mandark ipmon[105]: 19:40:47.440525 tun0 @100:14 b 216.72.52.94,1237 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:40:49 mandark ipmon[105]: 19:40:49.150630 tun0 @100:14 b 216.72.52.94,1237 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:41:26 mandark ipmon[105]: 19:41:26.141790 2x tun0 @100:14 b 24.229.86.45,4371 -> 212.123.189.17,8888 PR tcp len 20 64 -S IN > Jul 30 19:41:27 mandark ipmon[105]: 19:41:27.570976 tun0 @100:14 b 24.229.86.45,4371 -> 212.123.189.17,8888 PR tcp len 20 64 -S IN > Jul 30 19:41:28 mandark ipmon[105]: 19:41:28.280999 tun0 @100:14 b 24.229.86.45,4371 -> 212.123.189.17,8888 PR tcp len 20 64 -S IN > Jul 30 19:41:34 mandark ipmon[105]: 19:41:34.171088 2x tun0 @100:14 b 24.14.143.86,2054 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:41:35 mandark ipmon[105]: 19:41:35.521100 tun0 @100:14 b 24.14.143.86,2054 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:41:36 mandark ipmon[105]: 19:41:36.211107 tun0 @100:14 b 24.14.143.86,2054 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:41:39 mandark ipmon[105]: 19:41:38.041146 2x tun0 @100:14 b 62.136.26.149,1174 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:41:40 mandark ipmon[105]: 19:41:39.511138 tun0 @100:14 b 62.136.26.149,1174 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:41:46 mandark ipmon[105]: 19:41:45.931197 tun0 @100:14 b 213.217.170.230,1609 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:41:48 mandark ipmon[105]: 19:41:47.471238 tun0 @100:14 b 213.217.170.230,1609 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:41:50 mandark ipmon[105]: 19:41:49.171253 tun0 @100:14 b 213.217.170.230,1609 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:41:59 mandark ipmon[105]: 19:41:58.981382 tun0 @100:14 b 62.0.77.112,1687 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:42:01 mandark ipmon[105]: 19:42:00.671363 tun0 @100:14 b 62.0.77.112,1687 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:42:02 mandark ipmon[105]: 19:42:01.911390 tun0 @100:14 b 62.0.77.112,1687 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:42:02 mandark ipmon[105]: 19:42:02.011375 tun0 @100:14 b 63.42.158.65,3095 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:42:08 mandark ipmon[105]: 19:42:07.331469 2x tun0 @100:14 b 62.31.37.87,2375 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:42:09 mandark ipmon[105]: 19:42:08.561437 2x tun0 @100:14 b 62.31.37.87,2375 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:42:16 mandark ipmon[105]: 19:42:16.153864 tun0 @100:14 b 66.56.121.127,1950 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:42:17 mandark ipmon[105]: 19:42:17.201565 tun0 @100:14 b 66.56.121.127,1950 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN > Jul 30 19:42:18 mandark ipmon[105]: 19:42:17.904583 tun0 @100:14 b 66.56.121.127,1950 -> 212.123.189.17,8888 PR tcp len 20 48 -S IN To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Aug 5 14:28: 2 2001 Delivered-To: freebsd-security@freebsd.org Received: from vetica.com (unknown [204.209.140.14]) by hub.freebsd.org (Postfix) with SMTP id EF0C237B406 for ; Sun, 5 Aug 2001 14:27:58 -0700 (PDT) (envelope-from h410g3n@h410g3n.com) Received: (qmail 90169 invoked from network); 5 Aug 2001 21:27:56 -0000 Received: from enigma.pstis.net (HELO h410g3n.com) (209.115.180.175) by mail.vetica.com with SMTP; 5 Aug 2001 21:27:56 -0000 Message-ID: <3B6DB7A3.C55C744A@h410g3n.com> Date: Sun, 05 Aug 2001 15:16:19 -0600 From: h410G3n Organization: h410g3n-dotcommunists X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG Subject: 4.4-PRERELEASE Snoop Problems 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 I can't compile a kernel under 4.4-PRERELEASE with "pseudo-device snp 3" it errors out when I make depend. when I comment out the option my kernel builds fine?? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Aug 5 14:39:35 2001 Delivered-To: freebsd-security@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id 9961737B401 for ; Sun, 5 Aug 2001 14:39:32 -0700 (PDT) (envelope-from dtalk@prairienet.org) Received: from littleblue.spotnet.org (user-uini699.dsl.mindspring.com [165.121.25.41]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id OAA00077 for ; Sun, 5 Aug 2001 14:39:31 -0700 (PDT) Received: (qmail 22045 invoked from network); 5 Aug 2001 21:39:16 -0000 Received: from localhost (HELO littleblue) (127.0.0.1) by localhost with SMTP; 5 Aug 2001 21:39:16 -0000 Date: Sun, 5 Aug 2001 14:39:13 -0700 (PDT) From: David Talkington X-X-Sender: To: Subject: Re: multiple port scans: tcp/8888 In-Reply-To: <20010805223127.A4779@mandark.attica.home> Message-ID: 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----- Andre Goeree wrote: >Attached is part of my ipfilter log. The file shows port scans coming >in from 25 different IP addresses from all over the world (Europe, >USA, Asia) to tcp/8888. Since I could not find any information about >tcp/8888, any comments are appreciated. Solaris AnswerBook server runs on that port. It's powered by Sun's own web server, I believe. - -d - -- David Talkington http://www.spotnet.org PGP key: http://www.prairienet.org/~dtalk/dt000823.asc -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Made with pgp4pine 1.75-6 iQEVAwUBO229BL1ZYOtSwT+tAQE/wggAwi/olu/3MJnzCWNEOx2BsFW/MlMiV95e IRSCkgWY1w7HqzchAlTq+MqFGoD3T3WtHtlmd3Xvj5Zma7TUgLnTm5XJt9VtqMIQ HoaR9FF6EmKcEoMIQ6GMYEuEvViBDdosYoG97l4C2H29XGH8TtQL7kuAC2hOl/Mm wZKCbKuE+JoWkSP6Hl11ZI0IcO54GGlvEZ9j13nJrCEV48yEYjIpB2hm58K0yM2Z Ta5mhhpTnb5WJso6JURVlpHGknqiwr26qOw951bdbF6L2a2VWhDQPX9bNqo/567k 7zjsswe6jMnhdpckyXcvS2hAmtu7wAAsxEWK17E/WkT2XA0tKMbWLw== =Zu/g -----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 Aug 5 14:58:26 2001 Delivered-To: freebsd-security@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 061D137B401 for ; Sun, 5 Aug 2001 14:58:24 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 0153F81D01; Sun, 5 Aug 2001 16:58:13 -0500 (CDT) Date: Sun, 5 Aug 2001 16:58:13 -0500 From: Alfred Perlstein To: h410G3n Cc: freebsd-security@FreeBSD.ORG Subject: Re: 4.4-PRERELEASE Snoop Problems Message-ID: <20010805165813.N85642@elvis.mu.org> References: <3B6DB7A3.C55C744A@h410g3n.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B6DB7A3.C55C744A@h410g3n.com>; from h410g3n@h410g3n.com on Sun, Aug 05, 2001 at 03:16:19PM -0600 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 * h410G3n [010805 16:28] wrote: > I can't compile a kernel under 4.4-PRERELEASE with "pseudo-device > snp 3" it errors out when I make depend. when I comment out the > option my kernel builds fine?? Don't bother sending the error message, it makes it more challenging for us. :P Have you tried compiling with snp but without the unit qualifier: pseudo-device snp ? -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Aug 5 15:25:23 2001 Delivered-To: freebsd-security@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id CDE6037B403 for ; Sun, 5 Aug 2001 15:25:18 -0700 (PDT) (envelope-from roam@ringworld.nanolink.com) Received: (qmail 10081 invoked by uid 1000); 5 Aug 2001 22:24:10 -0000 Date: Mon, 6 Aug 2001 01:24:10 +0300 From: Peter Pentchev To: h410G3n Cc: freebsd-security@FreeBSD.ORG Subject: Re: 4.4-PRERELEASE Snoop Problems Message-ID: <20010806012409.A586@ringworld.oblivion.bg> Mail-Followup-To: h410G3n , freebsd-security@FreeBSD.ORG References: <3B6DB7A3.C55C744A@h410g3n.com> <20010805165813.N85642@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010805165813.N85642@elvis.mu.org>; from bright@mu.org on Sun, Aug 05, 2001 at 04:58:13PM -0500 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 Sun, Aug 05, 2001 at 04:58:13PM -0500, Alfred Perlstein wrote: > * h410G3n [010805 16:28] wrote: > > I can't compile a kernel under 4.4-PRERELEASE with "pseudo-device > > snp 3" it errors out when I make depend. when I comment out the > > option my kernel builds fine?? > > Don't bother sending the error message, it makes it more challenging > for us. :P > > Have you tried compiling with snp but without the unit qualifier: > > pseudo-device snp And another question on the side: you *have* build a recent config(8) before trying to compile the new kernel, right? That is: If you are compiling the kernel using the 'make buildkernel from /usr/src, you should have done a 'make buildworld' first. If you are compiling a standalone kernel (running config(8) by hand), you should have done either a 'make world' or a 'make installworld' after a 'buildworld' on these very sources (not the ones before updating). If you are using 'make world'.. it has probably taken care of config(8), but the buildworld/buildkernel combination is much preferred for 4.1 and onwards. If all of this is too unclear for you, that's probably because your question was a bit too unclear for us. At the very least you might have included the exact error message; the steps you have taken to build the kernel would also help; the FreeBSD version that you are trying to update from would not hurt, either; the exact kernel config would be an added bonus ;) G'luck, Peter -- .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Aug 5 18:14:16 2001 Delivered-To: freebsd-security@freebsd.org Received: from blinx.net (ns2.blinx.net [205.205.72.1]) by hub.freebsd.org (Postfix) with SMTP id 5C02137B405 for ; Sun, 5 Aug 2001 18:14:12 -0700 (PDT) (envelope-from wacky@blinx.net) Received: (qmail 38209 invoked from network); 6 Aug 2001 01:11:54 -0000 Received: from ce3021279-a.montvlle1.ct.home.com (HELO home) (@24.180.62.220) by www.blinx.net with SMTP; 6 Aug 2001 01:11:54 -0000 Message-ID: <003d01c11e14$0b90c220$0700a8c0@com.home.com> From: "Mike" To: "FreeBSD-SECURITY" References: <20010730192031.M59043-100000@epsilon.lucida.ca> Subject: Ftpd problem Date: Sun, 5 Aug 2001 21:06:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Hi, I'm running FreeBSD 4.3-STABLE as a web server. Recently we have been having a problem with ftpd. The user trys to login and when it asks for a password it says login incorrect. The /etc/shells are correct with his account and he is not listed in /etc/ftpusers. But he can also login via ssh2. But if root changes his password then it will work. It's only after the user changes his password after a certain amount of days. I do not see anything in /etc/login.conf that could be causing this problem. Does anybody know what might be?. I am e-mailing this because I believe its security related. -Mike ----- Original Message ----- From: "Matt Heckaman" To: "FreeBSD-SECURITY" Sent: Monday, July 30, 2001 7:22 PM Subject: Re: FreeBSD Security Advisory FreeBSD-SA-01:51.openssl > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [ not cc'd to Kris since I know he's on this list :) ] > > On Mon, 30 Jul 2001, FreeBSD Security Advisories wrote: > ... > : # cd /usr/src/ > : # patch -p < /path/to/patch > : # cd /usr/src/lib/libcrypto/ > ^^^^^^^^^^^^^^^^^^^^^^^ > Shouldn't this be /usr/src/secure/lib/libcrypto ? At least that is where > it's located on my 4.3-STABLE machine of April 21 2001. > > * Matt Heckaman - mailto:matt@LUCIDA.CA http://www.lucida.ca/gpg * > * GPG fingerprint - 53CA 8320 C8F6 32ED 9DDF 036E 3171 C093 4AD3 1364 * > > The Universe is run by the complex interweaving of three elements: > energy, matter, and enlightened self-interest. > -- G'Kar, "Survivors" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (FreeBSD) > Comment: http://www.lucida.ca/gpg > > iD8DBQE7ZewxMXHAk0rTE2QRAtXMAJ9i5ughcdoKD8Pw1V31eOY3n5Z66wCeIyak > 3XgSgXYtipGBKf1z7tgOwmw= > =Z0+U > -----END PGP SIGNATURE----- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Aug 5 18:53:27 2001 Delivered-To: freebsd-security@freebsd.org Received: from ringworld.nanolink.com (unknown [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 75ED337B401 for ; Sun, 5 Aug 2001 18:53:22 -0700 (PDT) (envelope-from roam@ringworld.nanolink.com) Received: (qmail 23242 invoked by uid 1000); 6 Aug 2001 01:52:14 -0000 Date: Mon, 6 Aug 2001 04:52:14 +0300 From: Peter Pentchev To: Mike Cc: FreeBSD-SECURITY Subject: Re: Ftpd problem Message-ID: <20010806045214.D586@ringworld.oblivion.bg> Mail-Followup-To: Mike , FreeBSD-SECURITY References: <20010730192031.M59043-100000@epsilon.lucida.ca> <003d01c11e14$0b90c220$0700a8c0@com.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003d01c11e14$0b90c220$0700a8c0@com.home.com>; from wacky@blinx.net on Sun, Aug 05, 2001 at 09:06:37PM -0400 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 Sun, Aug 05, 2001 at 09:06:37PM -0400, Mike wrote: > Hi, I'm running FreeBSD 4.3-STABLE as a web server. Recently we have been > having a problem with ftpd. The user trys to login and when it asks for a > password it says login incorrect. The /etc/shells are correct with his > account and he is not listed in /etc/ftpusers. But he can also login via > ssh2. But if root changes his password then it will work. It's only after > the user changes his password after a certain amount of days. I do not see > anything in /etc/login.conf that could be causing this problem. Does anybody > know what might be?. I am e-mailing this because I believe its security > related. Try adding a line saying 'crypt_default = des' to the /etc/auth.conf file. You might then need to rebuild libcrypt, I'm still not sure why this is so, but from a little non-authoritative experience on 3-4 machines it seems that libcrypt understands that crypt_default=des only after it is *built* while /etc/auth.conf has a crypt_default=des line. This makes next to no sense to me, but this is the way I got it to work on three machines here. So.. # echo 'crypt_default = des' >> /etc/auth.conf # cd /usr/src/lib/libcrypt # make cleandir # make depend # make all install # make cleandir Another workaround would be to have all your users tell you their passwords, so you can convert them to MD5.. but that would be kind of stupid :) G'luck, Peter -- If this sentence didn't exist, somebody would have invented it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Aug 5 21: 1:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from dirnafax (unknown [216.72.219.3]) by hub.freebsd.org (Postfix) with SMTP id 6743D37B401 for ; Sun, 5 Aug 2001 21:00:28 -0700 (PDT) (envelope-from empresas@cable.net.co) x-esmtp: 0 0 1 Message-ID: <2708289-2200181621320310@cable.net.co> X-EM-Version: 6, 0, 0, 4 X-EM-Registration: #00F06206106618006920 X-Priority: 3 Reply-To: empresas@cable.net.co From: "Empresas" To: freebsd-security@freebsd.org Subject: Base de Datos - 1.000 Empresas Date: Sun, 5 Aug 2001 21:13:20 -0500 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_94915C5ABAF209EF376268C8" X-SMTPExp-Version: 1, 0, 2, 13 X-SMTPExp-Registration: 00B0320C107602006905 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 This is a multi-part message in MIME format. ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: multipart/alternative; boundary="----=_NextPart_84815C5ABAF209EF376268C8" ------=_NextPart_84815C5ABAF209EF376268C8 Content-type: text/plain; charset="US-ASCII" EMPRESAS - Base de datos con las 1.000 Empresas más grandes de Colombia (ventas superiores a $20.000 millones anuales), con los siguientes campos: razón social, sigla, Nit, dirección, teléfono, fax, actividad empresarial (código CIIU Rev. 3.0), número de empleados, ciudad y departamento, cifras de Activos, Patrimonio, Ventas y Utilidad para los últimos cinco años (Incluye cifras del año 2.000). Adicional a esta base se encuentra la base de datos de directivos y ejecutivos de estas empresas (más de 9.500), con los siguientes campos: nombre, cargo, área por cargos, dirección, teléfono y fax. Estas bases de datos se encuentran relacionadas, la APLICACION que las maneja permite hacer búsquedas simples o complejas por todos los campos, agrupa diferentes tipos de búsquedas, prepara e imprime reportes, rótulos y cartas, hace llamadas telefónicas y envía email's. La aplicación es totalmente autónoma, es decir no necesita ningún software adicional para su total desempeño en Windows 95 o superior. COMO VALOR AGREGADO le damos acceso a toda la información sobre COMERCIO EXTERIOR (27.000 importadores y 4.000 exportadores), a través de enlaces Vía Internet a MINCOMEX, PROEXPORT Y LA COMUNIDAD ANDINA. También le facilitamos la conexión a sus propios enlaces. PRESENTACION - Las bases de datos y la aplicación se entregan en un CD, que permite la auto-instalación. VALOR DEL CD - Col$100.000, los cuales se deben depositar en COLMENA en la cuenta de ahorros No. 0114500194215 a nombre de Directorio Nacional de Fax, copia de la consignación con las instrucciones de entrega enviarlas al Fax 6178102/6179073 Bogotá y el CD y la factura serán enviados al día siguiente vía Servientrega. Si ya adquirió la versión 500 Empresas deposite únicamente Col$50.000 Empresas - Tr. 51A No 123-01 Int. 10 - Tel. 6135184 - Fax 6178102/6179073 - empresas@elsitio.net.co - Bogotá Colombia Si desea ser removido de esta base de datos, responda a este mensaje indicando - remover - en el subject ------=_NextPart_84815C5ABAF209EF376268C8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable EMPRESAS - Base de datos de las 500Empresas m=E1s grandes, (por ven= tas), del pa=EDs con los siguientes campos: raz=F3n social, sigla

EMPRESAS<= span style=3D'font-size:10=2E0pt;font-family:Arial;color:blue'> - Base de datos co= n las 1=2E000 Empresas m=E1s grandes de Colombia (ventas superiores a $20=2E000 mil= lones anuales), con los siguientes campos: raz=F3n social, sigla, Nit, direcci=F3n, tel=E9fono, fax, actividad empresarial (c=F3digo CIIU Rev=2E = 3=2E0), n=FAmero de empleados, ciudad y departamento, cifras de Activos, Patrimonio, Ventas= y Utilidad para los =FAltimos cinco a=F1os (Incluye cifras del a=F1o 2=2E000)=2E Adi= cional a esta base se encuentra la base de datos de directivos y ejecutivos de esta= s empresas (m=E1s de 9=2E500), con los siguientes campos: nombre, cargo, =E1= rea por cargos, direcci=F3n, tel=E9fono y fax=2E

 

Estas bases de datos se encuentran relacionadas, la APLICACION que las maneja permite hacer b=FAsquedas simpl= es o complejas por todos los campos, agrupa diferentes tipos de b=FAsquedas, prepara e im= prime reportes, r=F3tulos y cartas, hace llamadas telef=F3nicas y env=EDa email=92s=2E La aplicaci=F3n es totalmente aut=F3nom= a, es decir no necesita ning=FAn software adicional para su total desempe=F1o en Windows = 95 o superior=2E

 

COMO VALOR AGREGADO le damos acceso= a toda la informaci=F3n sobre COMERCIO EXTERIOR (27=2E000 importadores y 4=2E000 exportadores), a trav=E9s de enlaces V=EDa Internet a MINCOMEX, PROEXPORT = Y LA COMUNIDAD ANDINA=2E Tambi=E9n le facilitamos la conexi=F3n a sus propios e= nlaces=2E

 

PRESENTACION =96 Las bases de datos= y la aplicaci=F3n se entregan en un CD, que permite la auto-instalaci=F3n=2E

 

VALOR DEL CD=A0 - Col$100=2E000, los cuales se deben depositar en = COLMENA en la cuenta de ahorros No=2E 0114500194215 a nombre de Directorio Naciona= l de Fax, copia de la consignaci=F3n con las instrucciones de entrega enviarlas= al Fax 6178102/6179073 Bogot=E1 y el CD y la factura ser=E1n enviados al d=EDa si= guiente v=EDa Servientrega=2E Si ya adquiri=F3 la versi=F3n 500 Empresas deposite =FAnicamen= te Col$50=2E000

 

Empresas - Tr=2E 51A No 123-01 Int=2E 10 =96 Tel=2E 6135184 =96 Fax 6178102/6179073 =96 empresas@elsitio=2Enet=2Eco - Bogot=E1 Colombia

 

Si desea ser removido de esta base de datos, responda a este mensaje indicand= o =96 remover =96 en el subject

 

 

------=_NextPart_84815C5ABAF209EF376268C8-- ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-Description: image002.jpg Content-Id: <32600-2200181621347702285@cable.net.co> /9j/4AAQSkZJRgABAQEAYABgAAD//gAcU29mdHdhcmU6IE1pY3Jvc29mdCBPZmZpY2X/2wBDAAoH BwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8 SDc9Pjv/wAALCAJZAAgBAREA/8QAGQABAQEBAQEAAAAAAAAAAAAAAgEDAAUH/8QAFhABAQEAAAAA AAAAAAAAAAAAABES/90ABAAo/9oACAEBAAA/APSirFhFChQocOHDjSHGkaZPLTLSHDjSHChwoUKF FVVVXRUrn//Q+yIiIlGjRo0KNCs6FCs9M9BpnWdCs6FChQo0aNEalRK5/9k= ------=_NextPart_94915C5ABAF209EF376268C8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 0: 5:37 2001 Delivered-To: freebsd-security@freebsd.org Received: from zorg.agsmedia.pl (zorg.agsmedia.pl [193.41.120.12]) by hub.freebsd.org (Postfix) with ESMTP id B30A837B401 for ; Mon, 6 Aug 2001 00:05:34 -0700 (PDT) (envelope-from wtp@agsmedia.pl) Received: from pooh.panska.agsmedia.pl (pooh.panska.agsmedia.pl [169.254.253.6]) by zorg.agsmedia.pl (Postfix) with ESMTP id A963E7C03D; Mon, 6 Aug 2001 09:04:24 +0200 (CEST) Date: Mon, 6 Aug 2001 09:01:28 +0200 (CEST) From: Krzysztof Stryjek X-X-Sender: Reply-To: Krzysztof Stryjek To: Michael Scheidell Cc: Subject: Re: pam session failing In-Reply-To: <004101c11c2f$9ee4cd00$2801010a@fdma.com> Message-ID: 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 Hello! On Fri, 3 Aug 2001, Michael Scheidell wrote: > > > It's documentated in /usr/src/UPDATING. > > find a LARGER version of pam_unix.so in /usr/src/obj (somewhere) copied it > over and no more problems > (don't know why update/install didn't do it for me, but then again, lots of > things don't do it for me) > Because after that You should run mergemaster. It will make config updates for you. And as it was written earlier it's documented in UPDATING (grep -in mergemaster /usr/src/UPDATING) Regards -- Krzysztof Stryjek email: wtp@agsmedia.pl ICQ: 79525071 http://mud.pl/~wtp/ Never go to a doctor whose office plants have died. -- Erma Bombeck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 4:35:17 2001 Delivered-To: freebsd-security@freebsd.org Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.249.195.3]) by hub.freebsd.org (Postfix) with SMTP id 704E437B405 for ; Mon, 6 Aug 2001 04:35:12 -0700 (PDT) (envelope-from paulo@nlink.com.br) Received: (qmail 89007 invoked by uid 501); 6 Aug 2001 11:35:09 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Aug 2001 11:35:09 -0000 Date: Mon, 6 Aug 2001 08:35:09 -0300 (BRT) From: Paulo Fragoso To: Igor Podlesny Cc: Kris Kennaway , Subject: Re[2]: SSHD in JAIL In-Reply-To: <15963958557.20010804103012@morning.ru> Message-ID: <20010806082311.E84271-100000@mirage.nlink.com.br> 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 On Sat, 4 Aug 2001, Igor Podlesny wrote: > > > On Tue, Jul 31, 2001 at 06:35:28PM -0300, Paulo Fragoso wrote: > >> On Tue, 31 Jul 2001, Kris Kennaway wrote: > >> > >> > On Tue, Jul 31, 2001 at 05:53:21PM -0300, Paulo Fragoso wrote: > >> > > Hi, > >> > > > >> > > We are making a jail using FBSD 4.3-RELEASE but in the jail sshd can't > >> > > starting: > >> > > > >> > > ssh-keygen: no RSA support in libssl and libcrypto. See ssl(8). > >> > > > >> > > How we can buildworld with RSA support in libssl or libcrypto? > >> > > >> > The error message really means "I can't find /dev/urandom" :-) > >> > >> How we can start sshd in the jail using jail directory mounted with nodev? > > Let me ask what is the purpose of nodev in your situation? I was thinking if jail dir mounted on file system with "nodev" it will more secure. Anyone colud acess any disks in the jails enviroment. Is it all right? > > I suggest using devfs (5) mounted inside your jail dir (not sure, > though, how about urandom there, but think it should be okay)... seems > it will solve the problem. At least there is a hope there ;) > > > You can't: it needs /dev/urandom. > > Kris > Thanks, Paulo Fragoso. > -- > Igor mailto:poige@morning.ru > http://www.morning.ru/~poige > > -- __O _-\<,_ Why drive when you can bike? (_)/ (_) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 4:40:41 2001 Delivered-To: freebsd-security@freebsd.org Received: from unity.agava.ru (unity.agava.ru [213.59.3.227]) by hub.freebsd.org (Postfix) with ESMTP id 62B1937B403 for ; Mon, 6 Aug 2001 04:40:39 -0700 (PDT) (envelope-from frank@agava.com) Received: from relay2.agava.net.ru (unknown [193.125.142.2]) by unity.agava.ru (Postfix) with ESMTP id 2644927E849; Mon, 6 Aug 2001 15:40:33 +0400 (MSD) Received: from gw.office.agava.ru (2.oivt.mipt.ru [193.125.142.2]) by relay2.agava.net.ru (Postfix) with ESMTP id 7377F43854; Mon, 6 Aug 2001 15:39:56 +0400 (MSD) Received: from hellbell.domain (hellbell.domain [192.168.1.12]) by gw.office.agava.ru (Postfix) with ESMTP id E9A706087; Mon, 6 Aug 2001 15:39:42 +0400 (MSD) Received: from localhost (localhost [127.0.0.1]) by hellbell.domain (Postfix) with ESMTP id 968DDCCE5; Mon, 6 Aug 2001 15:39:42 +0400 (MSD) Date: Mon, 6 Aug 2001 15:39:42 +0400 (MSD) From: Alexey Zakirov X-X-Sender: To: Paulo Fragoso Cc: Subject: Re[2]: SSHD in JAIL In-Reply-To: <20010806082311.E84271-100000@mirage.nlink.com.br> Message-ID: 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 On Mon, 6 Aug 2001, Paulo Fragoso wrote: > I was thinking if jail dir mounted on file system with "nodev" it will > more secure. Anyone colud acess any disks in the jails enviroment. Is it > all right? yes, but you don't have to create all those disk device nodes. And of course you can't create a device node inside jail itself. *** WBR, Alexey Zakirov (frank@agava.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 6:35:25 2001 Delivered-To: freebsd-security@freebsd.org Received: from relay2.kornet.net (unknown [211.48.62.162]) by hub.freebsd.org (Postfix) with ESMTP id F02AF37B401; Mon, 6 Aug 2001 06:32:52 -0700 (PDT) (envelope-from clubfriend@clubfriend.com) Received: from bown112 (211.38.171.177) by relay2.kornet.net; 6 Aug 2001 22:32:55 +0900 Message-ID: <006801c11e7b$fe8f4f20$b1ab26d3@kornet.net> Reply-To: "Youn, Roy" From: "Youn, Roy" To: =?ks_c_5601-1987?B?wK/H0MC7wdi68cfPtMK60LKy?= Subject: =?ks_c_5601-1987?B?W8irurhdwK/H0Mb4xbq96sDPISEhyK69x8fRwbawxyEhtbXA/MfP?= =?ks_c_5601-1987?B?vLy/5CEhISE=?= Date: Mon, 6 Aug 2001 22:30:35 +0900 Organization: =?ks_c_5601-1987?B?x8G3o7XlIMCvx9C/+A==?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C11EC7.693216A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C11EC7.693216A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ICAgICAgICAgICANCg0KDQogICAgICAgICAgICC+yLPnx8+8vL/kIMfBt6O15SDAr8fQv/ggwNS0 z7TZLg0KICAgICAgICAgICAgursguN7Az8C6IMiruri43sDPwNS0z7TZLiDH47b0vvjAzCC43sDP wLsgurizu7XluK6w1CC1yCDBob+hILTrx9ggwcu828fVtM+02S4gDQoNCiAgICAgICAgICAgICog sc3Hz8DHIGVtYWlsIMGkuri0wiDIqMbkwMzB9iC51yCw1L3Dxse/obytIML8wbbHz7+0vcC0z7TZ Lg0KDQoNCiAgICAgICAgICAgIL+1vu6woSC09SDAzLvzwLoguaux4rChIL7GtNEgx8q89sD7wM4g v+S80rfOILTZsKG/wLTCIMDMIL3DtOu/oSDFq7W3IL7ItenAzLDttbUgx9i/3L+svPa/zSDAr7e0 ILnos7a/qcfgse7B9iC02bPgv8MgvPYgwNa0wrHiyLiwoSDA1r7uvK0gvNKwsyDH1bTPtNkuDQog ICAgICAgICAgICCx17DNtbUgwaTF67+1vu64piC56L/vILz2IMDWtMIgv7WxuSC3sbT4wMcgTE9O RE9OIEVOR0xJU0ggU0NIT09MIL+hvK0gwNS0z7TZLg0KDQogICAgICAgICAgICC6zrTjIL74tMIg sKGw3cC4t84gw+K538fPsO0gx/bB9r+hvK0gvsa4o7nZwMzGrsfPuOkgw+a60Mj3ILv9yLC68bim ILn6vPYgwNa9wLTPtNkuILbHx9Egv6y89rChILOhs6q46SCwobHuv+4gx8G2+726LCDAzMXCuK4g te4gv6m3ryDAr7e0s6q287fOILnos7a/qcfgwLsgtrCzryC89iDA1r3AtM+02S4NCg0KDQogICAg ICAgICAgICAgICAgICDH4LvnwM/BpCA0wvcgOS8zIDogMjAguO0gwaS/+CAoMrjtv6nArykgDQog ICAgICAgICAgICAgICAgICAoMjAwMbPiKSA1wvcgOS8yNCA6IDIwILjtIMGkv/ggIA0KICAgICAg ICAgICAgICAgICAgICA2wvcgMTAvMTkgOiAxNSC47SDBpL/4ICi4trCoKSANCiAgICAgICAgICAg ICAgICAgICAgN8L3IDExLzQgOiAxNSC47SDBpL/4IA0KDQogICAgICAgICAgICDC/LChuvEgOiC/ rLz2IDaws7/5seLB2CAzODAguLi/+CAvIL+svPYgMbPiILHiwdggNDQwILi4v/ggKMSrteUgsOHB piCwobTJKSAoKiogv6y89rHisKMgv6zA5bChtMkpDQogICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgICAgICDC/LChuvEgxvfH1LO7v6ogOiC/1bq5IMfXsPixxyAoNrCzv/mwoyks ILz2vve34SDA/L7XLCA0wdYgvPe52rrxICgywM4xvccpLCC89rzTt+EsIMPiud/A/CC80r7nsbPA sCwgseKz5CC6ubTrLCC/qcfgwNogurjH6Cwgx/bB9rChwMy15SAosPjH17nMxsMsILz3vNIsIMfQ sbMsIL7GuKO52cDMxq4pIA0KICAgICAgICAgICAgKrvzseIgsd2+18C6IMfQuvEgwPy+1yC51yDA z8O8IMb3x9TAzLbzILT1IMDMu/PAxyDD37ChILrxv+vAuiC++MC4uOcgv7m78yC7/ciwuvG/6yAo vPe9xLrxLCCxs8XrLCC/67W3KcC6IL/5IDcwuLi/+CC8scC4t84gvsa4o7nZwMzGriC89sDUwLi3 ziDD5rTnILChtMnH1bTPtNkuIA0KICAgICAgICAgICAgx/bB9iC+xrijudnAzMauIDogxLO8xSwg veG68Swgv6nH4LvnILChwMy15SC51yC757mrwfcsILzux84gvsa4o7nZwMzGriwgvcS05yC6uMG2 te4gDQogICAgICAgICAgICDH9sH2IL7GuKO52cDMxq4gvPbA1CA6IL3DsKO05yDD1sD6IDcsMDAw v/h+MTAsMDAwv/ggICAxwM8gNb3DsKMsIMHWIDXAzyCx2b3DIC0tLSAxsLO/+SDD1sD6ILz2wNQg NzC4uL/4IH4gMTAwuLi/+CANCg0KDQogICAgICAgICAgICDB9r/4IMDasN0gOiAxOLy8IMDMu/Mg s7IsILPgILSpsbizqiCwobTJICi0qbG4s6ogwK/H0LrxwNogMTAwJSC53r7GteW4sikNCg0KICAg ICAgICAgICAgwNq8vMfRILvnu/PAuiDIqMbkwMzB9iC55rmuwMyzqiC6u7vnt84gv6y29CDB1r3D uOkgw9a8scC7ILTZx9ggtbW/zSC15biusNq9wLTPtNkuDQogICAgICAgICAgICBodHRwOi8vd3d3 LmNsdWJmcmllbmQuY29tIC8gx8G3o7XlIMCvx9C/+CAwMzEtMzk2LTc5MDUvNg0KDQogICAgICAg ICAgICC9xcO7wLsgv/jHz73DtMK60MC6IMDMsPfAuyDF68fPv6kgvcXDu7ytuKYgud+828fPv6kg wda9w7HiILnZtvi0z7TZLg0KICAgICAgICAgICAgwbax4iC9xcO7wNq0wiC897zSILyxxcPAzLOq IL7GuKO52cDMxq4gvNKws73Dxq/A/MDMIMHWvu4gwf20z7TZLiANCg0KICAgICAgICAgICAgKrq7 IMCvx9C/+MC6IEJDIMSrteW75yC/tbG5v6y89iC788ewIMf5t8K+98O8IMDUtM+02S4NCg0KICAg ICAgICAgICANCiAgICAgDQoNCg== ------=_NextPart_000_0063_01C11EC7.693216A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPFRBQkxF IGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0aD01MDAgYm9yZGVyPTE+DQogIDxUQk9E WT4NCiAgPFRSPg0KICAgIDxURD4NCiAgICAgIDxUQUJMRSBjZWxsU3BhY2luZz0wIGNlbGxQYWRk aW5nPTAgd2lkdGg9NTAwIGJvcmRlcj0wPg0KICAgICAgICA8VEJPRFk+DQogICAgICAgIDxUUj4N CiAgICAgICAgICA8VEQgd2lkdGg9NTAwIGhlaWdodD0yNTA+DQogICAgICAgICAgICA8T0JKRUNU IA0KICAgICAgICAgICAgY29kZUJhc2U9aHR0cDovL2Rvd25sb2FkLm1hY3JvbWVkaWEuY29tL3B1 Yi9zaG9ja3dhdmUvY2Ficy9mbGFzaC9zd2ZsYXNoLmNhYiN2ZXJzaW9uPTUsMCwwLDAgDQogICAg ICAgICAgICBjbGFzc2lkPWNsc2lkOkQyN0NEQjZFLUFFNkQtMTFjZi05NkI4LTQ0NDU1MzU0MDAw MCB3aWR0aD01MDAgDQogICAgICAgICAgICBoZWlnaHQ9MjUwPjxQQVJBTSBOQU1FPSJfY3giIFZB TFVFPSIxMzIyOSI+PFBBUkFNIE5BTUU9Il9jeSIgVkFMVUU9IjY2MTUiPjxQQVJBTSBOQU1FPSJN b3ZpZSIgVkFMVUU9Imh0dHA6Ly9jbHViZnJpZW5kLmNvbS+xpLDtLnN3ZiI+PFBBUkFNIE5BTUU9 IlNyYyIgVkFMVUU9Imh0dHA6Ly9jbHViZnJpZW5kLmNvbS+xpLDtLnN3ZiI+PFBBUkFNIE5BTUU9 IldNb2RlIiBWQUxVRT0iV2luZG93Ij48UEFSQU0gTkFNRT0iUGxheSIgVkFMVUU9Ii0xIj48UEFS QU0gTkFNRT0iTG9vcCIgVkFMVUU9Ii0xIj48UEFSQU0gTkFNRT0iUXVhbGl0eSIgVkFMVUU9Ikhp Z2giPjxQQVJBTSBOQU1FPSJTQWxpZ24iIFZBTFVFPSIiPjxQQVJBTSBOQU1FPSJNZW51IiBWQUxV RT0iLTEiPjxQQVJBTSBOQU1FPSJCYXNlIiBWQUxVRT0iIj48UEFSQU0gTkFNRT0iU2NhbGUiIFZB TFVFPSJTaG93QWxsIj48UEFSQU0gTkFNRT0iRGV2aWNlRm9udCIgVkFMVUU9IjAiPjxQQVJBTSBO QU1FPSJFbWJlZE1vdmllIiBWQUxVRT0iMCI+PFBBUkFNIE5BTUU9IkJHQ29sb3IiIFZBTFVFPSIi PjxQQVJBTSBOQU1FPSJTV1JlbW90ZSIgVkFMVUU9IiI+PFBBUkFNIE5BTUU9IlN0YWNraW5nIiBW QUxVRT0iYmVsb3ciPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICA8ZW1iZWQg ICAgICAgICAgICAgICAgICAgICAgICAgc3JjPSJodHRwOi8vY2x1YmZyaWVuZC5jb20vsaSw7S5z d2YiIA0KICAgICAgICAgICAgcXVhbGl0eT1oaWdoICAgICAgICAgICAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgcGx1Z2luc3BhZ2U9Imh0dHA6Ly93d3cubWFjcm9tZWRpYS5jb20vc2hvY2t3 YXZlL2Rvd25sb2FkL2luZGV4LmNnaT9QMV9Qcm9kX1ZlcnNpb249U2hvY2t3YXZlRmxhc2giIA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0iYXBwbGljYXRpb24veC1z aG9ja3dhdmUtZmxhc2giIA0KICAgICAgICAgICAgd2lkdGg9IjUwMCIgICAgICAgICAgICAgaGVp Z2h0PSIyNTAiPiAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICA8L2VtYmVk PiAgICAgICAgICAgICAgICAgICAgICAgPC9PQkpFQ1Q+PC9URD48L1RSPg0KICAgICAgICA8VFI+ DQogICAgICAgICAgPFREPg0KICAgICAgICAgICAgPFA+Jm5ic3A7PC9QPg0KICAgICAgICAgICAg PFA+PEZPTlQgc2l6ZT0tMT6+yLPnx8+8vL/kIMfBt6O15SDAr8fQv/ggwNS0z7TZLjxCUj66uyC4 3sDPwLogyKu6uLjewM/A1LTPtNkuIMfjtvS++MDMILjewM/AuyC6uLO7teW4rrDUIA0KICAgICAg ICAgICAgtcggwaG/oSC068fYIMHLvNvH1bTPtNkuIDwvRk9OVD48L1A+DQogICAgICAgICAgICA8 UD48Rk9OVCBzaXplPS0xPiogsc3Hz8DHIGVtYWlsIMGkuri0wiDIqMbkwMzB9iC51yCw1L3Dxse/ obytIML8wbbHz7+0vcC0z7TZLjwvRk9OVD48L1A+DQogICAgICAgICAgICA8UD48Rk9OVCBzaXpl PS0xPjxCUj6/tb7usKEgtPUgwMy788C6ILmrseKwoSC+xrTRIMfKvPbA+8DOIL/kvNK3ziC02bCh v8C0wiDAzCC9w7Trv6Egxau1tyC+yLXpwMyw7bW1IA0KICAgICAgICAgICAgPEI+PEZPTlQgY29s b3I9IzAwMDA4MD7H2L/cv6y89r/NIMCvt7Qgueiztr+px+A8L0ZPTlQ+PC9CPrHuwfYgtNmz4L/D ILz2IMDWtMKx4si4sKEgwNa+7rytILzSsLMgDQogICAgICAgICAgICDH1bTPtNkuPEJSPrHXsM21 tSDBpMXrv7W+7rimILnov+8gvPYgwNa0wiC/tbG5ILextPjAxyA8Qj48Rk9OVCBjb2xvcj0jMDAw MDgwPkxPTkRPTiANCiAgICAgICAgICAgIEVOR0xJU0ggU0NIT09MPC9GT05UPjwvQj48Rk9OVCBj b2xvcj0jMDAwMDgwPiA8L0ZPTlQ+v6G8rSANCiAgICAgICAgICAgIMDUtM+02S48L0ZPTlQ+PC9Q Pg0KICAgICAgICAgICAgPFA+PEZPTlQgc2l6ZT0tMT66zrTjIL74tMIgsKGw3cC4t84gw+K538fP sO0gx/bB9r+hvK0gvsa4o7nZwMzGrsfPuOkgw+a60Mj3ILv9yLC68bimILn6vPYgwNa9wLTPtNku ILbHx9EgDQogICAgICAgICAgICC/rLz2sKEgs6GzqrjpILChse6/7iDHwbb7vbosIMDMxcK4riC1 7iC/qbevIMCvt7Szqrbzt84gueiztr+px+DAuyC2sLOvILz2IMDWvcC0z7TZLjwvRk9OVD48Rk9O VCANCiAgICAgICAgICAgIHNpemU9LTE+PEJSPjwvRk9OVD48L1A+DQogICAgICAgICAgICA8VEFC TEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSI4MCUiIGJvcmRlcj0wPg0KICAg ICAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgICAgIDxUUj4NCiAgICAgICAgICAgICAgICA8 VEQgd2lkdGg9IjI3JSI+PEZPTlQgc2l6ZT0tMT7H4LvnwM/BpDwvRk9OVD48L1REPg0KICAgICAg ICAgICAgICAgIDxURCB3aWR0aD0iMjIlIj48Rk9OVCBzaXplPS0xPjTC9yA5LzMgOjwvRk9OVD48 L1REPg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iNTElIj48Rk9OVCBzaXplPS0xPjIwILjt IMGkv/ggKDK47b+pwK8pPC9GT05UPjwvVEQ+PC9UUj4NCiAgICAgICAgICAgICAgPFRSPg0KICAg ICAgICAgICAgICAgIDxURCB3aWR0aD0iMjclIj48Rk9OVCBzaXplPS0xPigyMDAxs+IpPC9GT05U PjwvVEQ+DQogICAgICAgICAgICAgICAgPFREIHdpZHRoPSIyMiUiPjxGT05UIHNpemU9LTE+NcL3 IDkvMjQgOjwvRk9OVD48L1REPg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iNTElIj48Rk9O VCBzaXplPS0xPjIwILjtIMGkv/ggPC9GT05UPjwvVEQ+PC9UUj4NCiAgICAgICAgICAgICAgPFRS Pg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iMjclIj4mbmJzcDs8L1REPg0KICAgICAgICAg ICAgICAgIDxURCB3aWR0aD0iMjIlIj48Rk9OVCBzaXplPS0xPjbC9yAxMC8xOSA6PC9GT05UPjwv VEQ+DQogICAgICAgICAgICAgICAgPFREIHdpZHRoPSI1MSUiPjxGT05UIHNpemU9LTE+MTUguO0g waS/+CAouLawqCk8L0ZPTlQ+PC9URD48L1RSPg0KICAgICAgICAgICAgICA8VFI+DQogICAgICAg ICAgICAgICAgPFREIHdpZHRoPSIyNyUiPiZuYnNwOzwvVEQ+DQogICAgICAgICAgICAgICAgPFRE IHdpZHRoPSIyMiUiPjxGT05UIHNpemU9LTE+N8L3IDExLzQgOjwvRk9OVD48L1REPg0KICAgICAg ICAgICAgICAgIDxURCB3aWR0aD0iNTElIj48Rk9OVCBzaXplPS0xPjE1ILjtIA0KICAgICAgICAg ICAgwaS/+DwvRk9OVD48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxGT05UIHNpemU9LTE+PEJS PsL8sKG68SA6IL+svPYgPEZPTlQgDQogICAgICAgICAgICBjb2xvcj0jZmYwMDAwIHNpemU9Mz48 Qj42sLO/+bHiwdggMzgwILi4v/g8L0I+PC9GT05UPiAvIL+svPYgPEZPTlQgDQogICAgICAgICAg ICBzaXplPTM+PEI+PEZPTlQgY29sb3I9I2ZmMDAwMD4xs+IgseLB2CA0NDAguLi/+DwvRk9OVD48 L0I+IDwvRk9OVD4oxKu15SCw4cGmIA0KICAgICAgICAgICAgsKG0yTxGT05UIGNvbG9yPSMwMDAw ODA+KTwvRk9OVD4gKCoqIL+svPax4rCjIL+swOWwobTJKTxCUj48L0ZPTlQ+DQogICAgICAgICAg ICA8VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSIxMDAlIiBib3JkZXI9 MD4NCiAgICAgICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFI+DQogICAgICAgICAg ICAgICAgPFREIHdpZHRoPSIxOCUiPiZuYnNwOzwvVEQ+DQogICAgICAgICAgICAgICAgPFREIHdp ZHRoPSI4MiUiPiZuYnNwOzwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+DQogICAgICAgICAgICA8 VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSIxMDAlIiBib3JkZXI9MD4N CiAgICAgICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFI+DQogICAgICAgICAgICAg ICAgPFREIHZBbGlnbj10b3Agd2lkdGg9IjIyJSI+PEZPTlQgc2l6ZT0tMT7C/LChuvEgxvfH1LO7 v6ogOjwvRk9OVD48L1REPg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iNzglIj48Rk9OVCBz aXplPS0xPr/Vurkgx9ew+LHHICg2sLO/+bCjKSwgPEI+PEZPTlQgDQogICAgICAgICAgICAgICAg ICBjb2xvcj0jMDAwMDgwPrz2vve34SDA/L7XPC9GT05UPjwvQj4sIDTB1iC897nauvEgKDLAzjG9 xyksILz2vNO34Swgw+K538D8ILzSvuexs8CwLCANCiAgICAgICAgICAgICAgICAgILHis+Qgurm0 6ywgv6nH4MDaILq4x+gsIMf2wfawocDMteUgKLD4x9e5zMbDLCC897zSLCDH0LGzLCANCiAgICAg ICAgICAgIL7GuKO52cDMxq4pPC9GT05UPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEZPTlQg c2l6ZT0tMT4qu/Ox4iCx3b7XwLogx9C68SDA/L7XILnXIA0KICAgICAgICAgICAgwM/DvCDG98fU wMy28yA8Rk9OVCBjb2xvcj0jMDAwMDgwPjxCPrT1IMDMu/PAxyDD37ChILrxv+vAuiC++MC4uOc8 L0I+PC9GT05UPiC/ubvzILv9yLC68b/rIA0KICAgICAgICAgICAgKLz3vcS68SwgsbPF6ywgv+u1 tynAuiC/+SA3MLi4v/ggvLHAuLfOIL7GuKO52cDMxq4gvPbA1MC4t84gw+a05yCwobTJx9W0z7TZ LiA8L0ZPTlQ+DQogICAgICAgICAgICA8UD48Rk9OVCBzaXplPS0xPsf2wfYgvsa4o7nZwMzGriA6 IMSzvMUsIL3huvEsIL+px+C75yCwocDMteUgudcgu+e5q8H3LCC87sfOIL7GuKO52cDMxq4sIL3E tOcgurjBtrXuIA0KICAgICAgICAgICAgPEJSPsf2wfYgvsa4o7nZwMzGriC89sDUIDogvcOwo7Tn IMPWwPogNywwMDC/+H4xMCwwMDC/+CA8L0ZPTlQ+DQogICAgICAgICAgICA8VEFCTEUgY2VsbFNw YWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSIxMDAlIiBib3JkZXI9MD4NCiAgICAgICAgICAg ICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFI+DQogICAgICAgICAgICAgICAgPFREIHdpZHRo PSIyNyUiPiZuYnNwOzwvVEQ+DQogICAgICAgICAgICAgICAgPFREIHdpZHRoPSI3MyUiPjxGT05U IHNpemU9LTE+McDPIDW9w7CjLCDB1iA1wM8gsdm9wyAtLS0gMbCzv/kgw9bA+iC89sDUIA0KICAg ICAgICAgICAgICAgICAgNzC4uL/4IH4gMTAwuLi/+DwvRk9OVD48L1REPjwvVFI+PC9UQk9EWT48 L1RBQkxFPg0KICAgICAgICAgICAgPFA+PEZPTlQgc2l6ZT0tMT7B9r/4IMDasN0gOiA8Qj48Rk9O VCBjb2xvcj0jMDAwMDgwPjE4vLwgwMy78yCzsiwgs+AgtKmxuLOqIA0KICAgICAgICAgICAgsKG0 yTwvRk9OVD48L0I+ICi0qbG4s6ogwK/H0LrxwNogMTAwJSC53r7GteW4sik8L0ZPTlQ+PC9QPg0K ICAgICAgICAgICAgPFA+PEZPTlQgc2l6ZT0tMT7A2ry8x9Egu+e788C6IMioxuTAzMH2ILnmua7A zLOqILq7u+e3ziC/rLb0IMHWvcO46SDD1ryxwLsgtNnH2CC1tb/NIA0KICAgICAgICAgICAgteW4 rrDavcC0z7TZLjxCUj48QSBocmVmPSJodHRwOi8vY2x1YmZyaWVuZC5jb20iPmh0dHA6Ly93d3cu Y2x1YmZyaWVuZC5jb20gDQogICAgICAgICAgICA8L0E+LyDHwbejteUgwK/H0L/4IDAzMS0zOTYt NzkwNS82PC9GT05UPjwvUD4NCiAgICAgICAgICAgIDxQPjxGT05UIHNpemU9LTE+PEEgDQogICAg ICAgICAgICBocmVmPSJodHRwOi8vY2x1YmZyaWVuZC5jb20vc3VibWl0LWZyYW1lLmh0bWwiPjxC PjxGT05UIA0KICAgICAgICAgICAgY29sb3I9IzAwMDA4MD69xcO7wLsgv/jHz73DtMK60MC6IMDM sPfAuyDF68fPv6kgvcXDu7ytuKYgud+82zwvRk9OVD48L0I+PC9BPsfPv6kgwda9w7HiIA0KICAg ICAgICAgICAgudm2+LTPtNkuPEJSPsG2seIgvcXDu8DatMIgvPe80iC8scXDwMyzqiC+xrijudnA zMauILzSsLO9w8avwPzAzCDB1r7uIMH9tM+02S4gPC9GT05UPjwvUD4NCiAgICAgICAgICAgIDxQ PjxGT05UIHNpemU9LTE+PEI+PEZPTlQgY29sb3I9IzAwMDA4MD4qursgwK/H0L/4wLogQkMgxKu1 5bvnIL+1sbm/rLz2ILvzx7Agx/m3wr73w7wgDQogICAgICAgICAgICDA1LTPtNkuPC9GT05UPjwv Qj48L0ZPTlQ+PC9QPg0KICAgICAgICAgICAgPFA+PC9QPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFC TEU+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4N Cg== ------=_NextPart_000_0063_01C11EC7.693216A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 6:45:11 2001 Delivered-To: freebsd-security@freebsd.org Received: from xs4nobody.nl (xs4nobody.nl [62.58.36.22]) by hub.freebsd.org (Postfix) with SMTP id 6EA9337B401 for ; Mon, 6 Aug 2001 06:45:06 -0700 (PDT) (envelope-from bart@xs4nobody.nl) Received: (qmail 32962 invoked by uid 1000); 6 Aug 2001 13:45:04 -0000 Date: Mon, 6 Aug 2001 15:45:04 +0200 From: Bart Matthaei To: freebsd-security@freebsd.org Subject: Re: =?iso-8859-1?Q?=5B=C8=AB=BA=B8=5D=C0=AF=C7=D0=C6=F8=C5=BA=BD=EA=C0=CF!!!?= =?iso-8859-1?Q?=C8=AE=BD=C7=C7=D1=C1=B6=B0=C7!!=B5=B5=C0=FC=C7=CF=BC=BC?= =?iso-8859-1?Q?=BF=E4!!!!?= Message-ID: <20010806154504.A32946@heresy.xs4nobody.nl> Reply-To: Bart Matthaei References: <006801c11e7b$fe8f4f20$b1ab26d3@kornet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006801c11e7b$fe8f4f20$b1ab26d3@kornet.net>; from clubfriend@clubfriend.com on Mon, Aug 06, 2001 at 10:30:35PM +0900 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 Huh ? chinese spam ? :> Gr, Bart Matthaei -- Bart Matthaei | bart@xs4nobody.nl | +31 6 24907042 Cysonet Managed Hosting | bart@cysonet.com ------------------------------------------------- /* It's always funny until someone gets hurt.. * (and then it's just hilarious) */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 6:56:57 2001 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (dav17.law15.hotmail.com [64.4.22.121]) by hub.freebsd.org (Postfix) with ESMTP id 3F55C37B401 for ; Mon, 6 Aug 2001 06:56:53 -0700 (PDT) (envelope-from nicole_caporusso@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 6 Aug 2001 06:56:52 -0700 X-Originating-IP: [207.159.100.187] From: "David Kutcher" To: References: <006801c11e7b$fe8f4f20$b1ab26d3@kornet.net> <20010806154504.A32946@heresy.xs4nobody.nl> Subject: translation of the spam Date: Mon, 6 Aug 2001 09:56:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: X-OriginalArrivalTime: 06 Aug 2001 13:56:52.0972 (UTC) FILETIME=[A584FAC0:01C11E7F] 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 Just in case you were interested, it was Korean spam (a little spicier than the chinese variant) the text below was the translation from babelfish at http://world.altavista.com/ (because I was curious) ---------------- How are you, phu it is land studying abroad won. The mail which it sees is the public information mail. Permission it sends the mail without and it is given and and regarding the point it is sorry. * You email information referred from home page and the notice board. English does not admit and and more over in this times which approaches with the essential element where the weapon is not the big money until overseas annual income and Europe knapsack travel there is it introduces a chance which is the possibility of geting back. It is from a LONDON ENGLISH of British London which is the possibility it of learning orthodox English SCHOOL. It departs at the price which is not charge and when it does a side job from the actual place, enough living expenses there is a punishment possibility. When also the annual income is over, near France, thay li there is a possibility of leaving a knapsack travel with the back multi Europe country. Event schedule 4th 9/3: 20 person regular staffs (2 person rooms) (2001 years) 5th 9/24: 20 person regular staffs 6th 10/19: 15 person regular staffs (close) 7th 11/4: 15 person regular staffs Participation rain: Annual income 6 month standard 380 full house / annual income 1 year standard 440 full house (card settlement possibility) (** annual income duration continuation possibility) Participation non- inclusion particulars: Reciprocation aviation volume (6 month for), the knowledge education the before the tuition fee total amount, 4 week lodging charges (1 thread which is 2), the process fee and departure and commemoration health band and traveler insurance, the actual place guide (airport America thing, quarters and school, side job) * minute description amount of money the educational expense total amount and all inclusion is not a additonal expenses of over more and the forecast living expenses (boarding and lodging rain, traffic and pocket money) with the month 70 full line appropriation is possible at side job income. Actual place side job: khay It is sour, it is bitter the rain, the travel agency guide and company unemployment and shopping side job, dining room cadence back actual place side job income: Per hour the lowest 7,000 won ~10,000 won 1 days 5 hours, week 5 day nearsighted --- 1 month lowest income 70 full house ~ 100 full house Support qualification: 18 three over south, nye who B possibility (who or studying abroad visa 100% receiving streamer) Detailed the thought where when liaison it gives with a home page visit or the head office, will finish the best and the tile it will give. }http{: //www.clubfriend.com / phu Land studying abroad won 031-396-7905/6 Wants an application the minute when this place to lead, to send out from an application, it wishes. Early rising application the quarters selection which sleeps or side job introduction hour privilege comes to give. * Studying abroad won which it sees is the BC card company British annual income goods cooperative enterprise. --------------- ----- Original Message ----- From: "Bart Matthaei" To: Sent: Monday, August 06, 2001 9:45 AM Subject: Re: [È«º¸]À¯ÇÐÆøź½êÀÏ!!!È®½ÇÇÑÁ¶°Ç!!µµÀüÇϼ¼¿ä!!!! > Huh ? chinese spam ? :> > > Gr, > > Bart Matthaei > > -- > Bart Matthaei | bart@xs4nobody.nl > | +31 6 24907042 > Cysonet Managed Hosting | bart@cysonet.com > ------------------------------------------------- > /* It's always funny until someone gets hurt.. > * (and then it's just hilarious) */ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 7:16:35 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.bacxs.com (ubr-b-33.137.247.winterpark.cfl.rr.com [65.33.137.247]) by hub.freebsd.org (Postfix) with ESMTP id 4667637B401 for ; Mon, 6 Aug 2001 07:16:31 -0700 (PDT) (envelope-from mwoodson@bacxs.com) Received: from efx.bacxs.com by mail.bacxs.com with SMTP (MDaemon.v3.5.3.R) for ; Mon, 06 Aug 2001 10:16:24 -0400 Message-Id: <5.1.0.14.0.20010806101346.0255fa38@192.168.99.2> X-Sender: mwoodson@192.168.99.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 06 Aug 2001 10:16:23 -0400 To: From: Mark Woodson Subject: Re: translation of the spam In-Reply-To: References: <006801c11e7b$fe8f4f20$b1ab26d3@kornet.net> <20010806154504.A32946@heresy.xs4nobody.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Return-Path: mwoodson@bacxs.com X-MDaemon-Deliver-To: freebsd-security@freebsd.org Reply-To: mwoodson@bacxs.com 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 09:56 AM 8/6/2001 -0400, David Kutcher wrote: >Just in case you were interested, it was Korean spam (a little spicier than >the chinese variant) > >the text below was the translation from babelfish at >http://world.altavista.com/ (because I was curious) I love there being free tools like babelfish, but automatic translation still has a long way to go. Though I did love this bit: "It is sour, it is bitter the rain" Seems a lot more poetic than I thought a spammer would be (but it's probably a translation side effect). -Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 7:31:18 2001 Delivered-To: freebsd-security@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 959A437B403 for ; Mon, 6 Aug 2001 07:31:14 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.4/8.11.4) id f76EV2Y59543; Mon, 6 Aug 2001 18:31:03 +0400 (MSD) (envelope-from ache) Date: Mon, 6 Aug 2001 18:30:59 +0400 From: "Andrey A. Chernov" To: Bill Fenner Cc: freebsd-security@FreeBSD.ORG Subject: Re: Opie and protecting passphrases Message-ID: <20010806183056.A59504@nagual.pp.ru> References: <200108051858.LAA15976@windsor.research.att.com> <20010806001807.A47300@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010806001807.A47300@nagual.pp.ru> User-Agent: Mutt/1.3.19i 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 More thoughts from another thread: Restricting opiepasswd _weakens_ security, because force user to ask admin to change password each time (f.e. when OPIE countdown goes to 0 or in case secret phrase becomes accidentally known). Any type of admin asking (by phone, by email) produce reaction time lag, in that period intruder can use secret phrase or user don't have its access. Email asking additionly transmit passwords over insecure channel. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 7:31:40 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.inka.de (quechua.inka.de [212.227.14.2]) by hub.freebsd.org (Postfix) with ESMTP id 9A06537B406 for ; Mon, 6 Aug 2001 07:31:37 -0700 (PDT) (envelope-from daemon@mips.inka.de) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with local-bsmtp id 15TlPs-0002FH-01; Mon, 6 Aug 2001 16:31:36 +0200 Received: (from daemon@localhost) by kemoauc.mips.inka.de (8.11.5/8.11.1) id f76ER9e01940 for freebsd-security@freebsd.org; Mon, 6 Aug 2001 16:27:09 +0200 (CEST) (envelope-from daemon) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Tracing writes? Date: Mon, 6 Aug 2001 14:27:08 +0000 (UTC) Message-ID: <9km9fr$1sb$1@kemoauc.mips.inka.de> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-security@freebsd.org 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 see that a file is written to. How do you figure out where the write() is coming from? As I have described on -current, executables keep getting new mtimes on my box (FreeBSD-CURRENT/alpha). Comparing MD5-Hashes of the files before and after, as well as copying the files to an entirely different system and comparing hashes there shows no changes. I've set up a little program that uses a kqueue() filter to watch over /bin/*. I expected to see utimes() updates (NOTE_ATTRIB), but it's telling me that the executables are actually _written_ to (NOTE_WRITE). I'm skeptical that I'm dealing with a security breach here, but something is going on I don't understand, and that in itself is worrying. Suggestions how to nail down the source of those write()s? -- Christian "naddy" Weisgerber naddy@mips.inka.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 8: 6: 2 2001 Delivered-To: freebsd-security@freebsd.org Received: from blues.jpj.net (unknown [204.97.17.6]) by hub.freebsd.org (Postfix) with ESMTP id 7FE8237B401 for ; Mon, 6 Aug 2001 08:05:59 -0700 (PDT) (envelope-from trevor@jpj.net) Received: from localhost (trevor@localhost) by blues.jpj.net (8.11.1/8.11.1) with ESMTP id f76F5t322849; Mon, 6 Aug 2001 11:05:55 -0400 (EDT) Date: Mon, 6 Aug 2001 11:05:54 -0400 (EDT) From: Trevor Johnson To: Christian Weisgerber Cc: Subject: Re: Tracing writes? In-Reply-To: <9km9fr$1sb$1@kemoauc.mips.inka.de> Message-ID: <20010806105944.N19105-100000@blues.jpj.net> 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 > Suggestions how to nail down the source of those write()s? Maybe do "chflags -R schg /bin/" and wait for new error messages? Of course, that would tip off the intruder, if there were one. -- Trevor Johnson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 9:29:45 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id 8A9AA37B401 for ; Mon, 6 Aug 2001 09:29:42 -0700 (PDT) (envelope-from fschapachnik@vianetworks.com.ar) Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.9.3/8.9.3) id NAA66095 for freebsd-security@freebsd.org; Mon, 6 Aug 2001 13:28:32 -0300 (ART) X-Authentication-Warning: ns1.via-net-works.net.ar: fpscha set sender to fschapachnik@vianetworks.com.ar using -f Date: Mon, 6 Aug 2001 13:28:32 -0300 From: Fernando Schapachnik To: freebsd-security@freebsd.org Subject: ssh keepalive and dynamic rules Message-ID: <20010806132832.A61827@ns1.via-net-works.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i 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 Hello, On a bridging firewall using ipfw I noticed that ssh conections get hung after an inactivity period. On some tests, tcpdumping the connection between two FreeBSD machines, both client and server with ssh "KeepAlive yes", I don't see any kind of keep alive traffic. dyn_ack timeout could be raised, but doesn't seem a proper solution. Any ideas on why ssh is not sending keepalive packets? Thanks! Fernando P. Schapachnik Planificación de red y tecnología VIA NET.WORKS ARGENTINA S.A. fschapachnik@vianetworks.com.ar Tel.: (54-11) 4323-3381 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 10:46:46 2001 Delivered-To: freebsd-security@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id B5C0F37B405 for ; Mon, 6 Aug 2001 10:46:43 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.11.4/8.11.1) id f76HkW958519; Mon, 6 Aug 2001 12:46:32 -0500 (CDT) Date: Mon, 6 Aug 2001 12:46:32 -0500 From: "Matthew D. Fuller" To: Christian Weisgerber Cc: freebsd-security@FreeBSD.ORG Subject: Re: Tracing writes? Message-ID: <20010806124632.G2134@futuresouth.com> References: <9km9fr$1sb$1@kemoauc.mips.inka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9km9fr$1sb$1@kemoauc.mips.inka.de>; from naddy@mips.inka.de on Mon, Aug 06, 2001 at 02:27:08PM +0000 X-OS: FreeBSD 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 Mon, Aug 06, 2001 at 02:27:08PM +0000, a little birdie told me that Christian Weisgerber remarked > You see that a file is written to. How do you figure out where the > write() is coming from? There may not be a write(). > As I have described on -current, executables keep getting new mtimes > on my box (FreeBSD-CURRENT/alpha). Comparing MD5-Hashes of the > files before and after, as well as copying the files to an entirely > different system and comparing hashes there shows no changes. I've > set up a little program that uses a kqueue() filter to watch over > /bin/*. I expected to see utimes() updates (NOTE_ATTRIB), but it's > telling me that the executables are actually _written_ to (NOTE_WRITE). There was at some time in the past a bug in the VM system that would cause mtimes to be updated because of (from memory) dirtied pages in the in-core copy of an executable being flushed back. I believe it was supposed to have been fixed (this was back in 2.2 days, IIRC), but it could be rearing its head again, or a similar bug doing so. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 12:30:41 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.inka.de (quechua.inka.de [212.227.14.2]) by hub.freebsd.org (Postfix) with ESMTP id EA21C37B403 for ; Mon, 6 Aug 2001 12:30:38 -0700 (PDT) (envelope-from daemon@mips.inka.de) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with local-bsmtp id 15Tq5F-000419-00; Mon, 6 Aug 2001 21:30:37 +0200 Received: (from daemon@localhost) by kemoauc.mips.inka.de (8.11.5/8.11.1) id f76JBMA41234 for freebsd-security@freebsd.org; Mon, 6 Aug 2001 21:11:22 +0200 (CEST) (envelope-from daemon) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: Tracing writes? Date: Mon, 6 Aug 2001 19:11:20 +0000 (UTC) Message-ID: <9kmq4o$185l$1@kemoauc.mips.inka.de> References: <9km9fr$1sb$1@kemoauc.mips.inka.de> <20010806124632.G2134@futuresouth.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-security@freebsd.org 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 Matthew D. Fuller wrote: > > You see that a file is written to. How do you figure out where the > > write() is coming from? > > There may not be a write(). True, but if there is, how to find it? > There was at some time in the past a bug in the VM system that would > cause mtimes to be updated because of (from memory) dirtied pages in the > in-core copy of an executable being flushed back. Yes, I suspect something like this. But for the purposes of -security: What ways are there to identify a rogue process writing to some file it isn't supposed to touch? -- Christian "naddy" Weisgerber naddy@mips.inka.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 14:47:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E66D637B405; Mon, 6 Aug 2001 14:47:04 -0700 (PDT) (envelope-from security-advisories@FreeBSD.org) Received: (from kris@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f76Ll4Q01611; Mon, 6 Aug 2001 14:47:04 -0700 (PDT) (envelope-from security-advisories@FreeBSD.org) Date: Mon, 6 Aug 2001 14:47:04 -0700 (PDT) Message-Id: <200108062147.f76Ll4Q01611@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: kris set sender to security-advisories@FreeBSD.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-01:42.signal [REVISED] Reply-To: security-advisories@FreeBSD.org 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----- ============================================================================= FreeBSD-SA-01:42 Security Advisory FreeBSD, Inc. Topic: signal handling during exec may allow local root compromise Category: core Module: kernel Announced: 2001-07-10 Revised: 2001-08-06 Credits: Georgi Guninski Affects: All released versions of FreeBSD 4.x, FreeBSD 4.3-STABLE prior to the correction date. Corrected: 2001-07-09 FreeBSD only: Yes 0. Revision History 2001-07-10 v1.0 Initial release 2001-08-06 v1.1 Binary upgrade package available I. Background When a process forks, it inherits the parent's signals. When the process execs, the kernel clears the signal handlers because they are not valid in the new address space. II. Problem Description A flaw exists in FreeBSD signal handler clearing that would allow for some signal handlers to remain in effect after the exec. Most of the signals were cleared, but some signal hanlders were not. This allowed an attacker to execute arbitrary code in the context of a setuid binary. All versions of 4.x prior to the correction date including and 4.3-RELEASE are vulnerable to this problem. The problem has been corrected by copying the inherited signal handlers and resetting the signals instead of sharing the signal handlers. III. Impact Local users may be able to gain increased privileges on the local system. IV. Workaround Do not allow untrusted users to gain access to the local system. V. Solution One of the following: 1) Upgrade your vulnerable FreeBSD system to 4.3-STABLE after the correction date. 2) To patch your present system: download the relevant patch from the below location, and execute the following commands as root: [FreeBSD 4.1, 4.2, and 4.3 base systems] This patch has been verified to apply to FreeBSD 4.1, 4.2, and 4.3 only. It may or may not apply to older releases. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:42/signal-4.3.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:42/signal-4.3.patch.asc Verify the detached PGP signature using your PGP utility. # cd /usr/src/sys/kern # patch -p < /path/to/patch [ Recompile your kernel as described in http://www.freebsd.org/handbook/kernelconfig.html and reboot the system ] 3) FreeBSD 4.3-RELEASE systems: An experimental upgrade package is available for users who wish to provide testing and feedback on the binary upgrade process. This package may be installed on FreeBSD 4.3-RELEASE systems only, and is intended for use on systems for which source patching is not practical or convenient. If you use the upgrade package, feedback (positive or negative) to security-officer@FreeBSD.org is requested so we can improve the process for future advisories. Since this vulnerability involves the FreeBSD kernel which is often locally customized on installed systems, a universal binary upgrade package is not feasible. This package includes a patched version of the GENERIC kernel which should be suitable for use on many systems. Systems requiring a customized kernel must use an alternative solution. During the installation procedure, backup copies are made of the files which are replaced by the package. These backup copies will be reinstalled if the package is removed, reverting the system to a pre-patched state. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:42/security-patch-signal-01.42.tgz # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:42/security-patch-signal-01.42.tgz.asc Verify the detached PGP signature using your PGP utility. # pkg_add security-patch-signal-01.42.tgz The new kernel is named /kernel.GENERIC to avoid conflict with the default kernel name (``/kernel''). To cause the system to boot automatically with the new kernel, add the following line to /boot/loader.conf: kernel="/kernel.GENERIC" and reboot the system to load the new kernel. The old kernel is still available and can be manually loaded in the boot loader in case of problems. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iQCVAwUBO28Pu1UuHi5z0oilAQHjeAQAmND4sSS6k1RHCz+uHSQb6hrX6vkKDr2M /9EMf/S90WFwVfIi7ifEgeY3U6XJpRd2Bdx1rCPOCMdSYkehd+WqVM8ZSgHkbpAL vrwS8KHrcC/G7KhCGzH5c6PjZYISdHXi4hWB9aV11zmmJZk3wL5GlIAaH8Dik403 w2SjxgHHM8w= =qVIE -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 15:15:35 2001 Delivered-To: freebsd-security@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 60CDB37B403; Mon, 6 Aug 2001 15:15:05 -0700 (PDT) (envelope-from security-advisories@FreeBSD.org) Received: (from kris@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f76MF5506589; Mon, 6 Aug 2001 15:15:05 -0700 (PDT) (envelope-from security-advisories@FreeBSD.org) Date: Mon, 6 Aug 2001 15:15:05 -0700 (PDT) Message-Id: <200108062215.f76MF5506589@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: kris set sender to security-advisories@FreeBSD.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-01:52.fragment Reply-To: security-advisories@FreeBSD.org 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----- ============================================================================= FreeBSD-SA-01:52 Security Advisory FreeBSD, Inc. Topic: Denial of service using fragmented IPv4 packets Category: kernel Announced: 2001-08-06 Credits: "James Thomas" via NetBSD Affects: All releases of FreeBSD 3.x, 4.x prior to 4.4, FreeBSD 4.3-STABLE prior to the correction date Corrected: 2001-06-16 23:48:04 UTC (FreeBSD 4.3-STABLE) 2001-08-05 23:08:26 UTC (RELENG_4_3) 2001-08-06 09:20:57 UTC (FreeBSD 3.5.1-STABLE) FreeBSD only: NO I. Background The IP protocol allows datagrams (``packets'') to be fragmented in transit to allow transportation by lower layers with a smaller frame size than the desired IP datagram size. The fragments are collected and reassembled on the destination system. II. Problem Description Remote users may be able to prevent a FreeBSD system from communicating with other systems on the network by transmitting large numbers of fragmented IPv4 datagrams. For the attack to be effective, the attacker must have a high-bandwidth connection to the target system (for example, connected via a local network or over a fast remote network connection). IP datagram fragments destined to the target system will be queued for 30 seconds, to allow fragmented datagrams to be reassembled. Until recently, there was no upper limit in the number of reassembly queues. Therefore, a malicious party may be able to transmit a lot of bogus fragmented datagrams (with different IPv4 identification field) and cause the target system to exhaust its mbuf pool, preventing further network traffic processing or generation while the starvation condition continues. To solve this problem an upper limit was placed on the number of fragment reassembly queues. This value is tunable at runtime using the net.inet.ip.maxfragpackets sysctl: the sysctl is set to a default value at system startup but may be tuned up or down depending on the role of the system (e.g. if the system is a busy server which typically receives a lot of fragmented datagrams, you may want to set the value higher). The old system behaviour of an unlimited number of reassembly queues can be obtained by setting this sysctl to a negative value. Note however that attackers are still able to prevent legitimate fragmented IPv4 traffic from being reassembled by flooding the system with bogus fragmented datagrams and keeping the reassembly queues full. Unfragmented IPv4 communications will be unaffected by such an attack when this variable is set. All versions of FreeBSD 3.x and 4.x prior to the correction date including 3.5.1-RELEASE and 4.3-RELEASE are vulnerable to this problem, although exploitation is mitigated by the need for high-bandwidth access to the target machine. III. Impact IPv4-connected systems can be put into a resource-starved state from which they are unable to send or receive network traffic by the constant bombardment of the system by fragmented datagrams. IV. Workaround A possible workaround for systems which are under active attack is to increase the value of the NMBCLUSTERS kernel option on attacked machines and rebuild the kernel as described in the following URL: http://www.freebsd.org/handbook/kernelconfig.html This may provide a temporary solution until the patch can be applied: normally, it is the cluster mbufs which are exhausted by this attack. By setting NMBCLUSTERS to a higher value, you may be able to prevent the mbuf memory pool from being starved. VI. Solution One of the following: 1) Upgrade your vulnerable FreeBSD system to 4.3-STABLE or the RELENG_4_3 security-fix branch dated after the correction date. 2) To patch your present system: download the relevant patch from the below location, and execute the following commands as root: [FreeBSD 4.x] This patch has been verified to apply to FreeBSD 4.2-RELEASE and 4.3-RELEASE systems. It may or may not apply to older, unsupported releases. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:52/frag-4.x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:52/frag-4.x.patch.asc [FreeBSD 3.x] This patch has been verified to apply to FreeBSD 3.5.1-RELEASE systems. It may or may not apply to older, unsupported releases. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:52/frag-3.x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:52/frag-3.x.patch.asc Verify the detached PGP signature using your PGP utility. # cd /usr/src/ # patch -p < /path/to/patch Rebuild the kernel as described in the following URL: http://www.freebsd.org/handbook/kernelconfig.html 3) FreeBSD 4.3-RELEASE systems: An experimental upgrade package is available for users who wish to provide testing and feedback on the binary upgrade process. This package may be installed on FreeBSD 4.3-RELEASE systems only, and is intended for use on systems for which source patching is not practical or convenient. If you use the upgrade package, feedback (positive or negative) to security-officer@FreeBSD.org is requested so we can improve the process for future advisories. Since this vulnerability involves the FreeBSD kernel which is often locally customized on installed systems, a universal binary upgrade package is not feasible. This package includes a patched version of the GENERIC kernel which should be suitable for use on many systems. Systems requiring a customized kernel must use an alternative solution. During the installation procedure, backup copies are made of the files which are replaced by the package. These backup copies will be reinstalled if the package is removed, reverting the system to a pre-patched state. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:52/security-patch-fragment-01.52.tgz # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:52/security-patch-fragment-01.52.tgz.asc Verify the detached PGP signature using your PGP utility. # pkg_add security-patch-fragment-01.52.tgz The new kernel is named /kernel.GENERIC to avoid conflict with the default kernel name (``/kernel''). To cause the system to boot automatically with the new kernel, add the following line to /boot/loader.conf: kernel="/kernel.GENERIC" and reboot the system to load the new kernel. The old kernel is still available and can be manually loaded in the boot loader in case of problems. VII. Credits/References NetBSD wrote the original advisory from which large portions of this advisory was taken. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iQCVAwUBO28VK1UuHi5z0oilAQHU9AQAor9fi3Lp5Xtny/zPJpVcX4+96WvsqX4e j7xtydSKwbZg78AxCYzD53FnZ/Tmb0XCf6if0L+k4QFzBsmavauB2hoszJMuT1x0 WdcQmBvzIy5Oibffv88Kev760K7icdkskWYTLPJMxmP0dec9NZBLkTcR6udMyy2u JbK9HknLMiE= =8PO/ -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 15:55:23 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10]) by hub.freebsd.org (Postfix) with ESMTP id 988D537B405; Mon, 6 Aug 2001 15:55:15 -0700 (PDT) (envelope-from agifford@infowest.com) Received: from eq.net (eq.net [208.186.104.163]) by ns1.infowest.com (Postfix) with SMTP id 22B422135B; Mon, 6 Aug 2001 16:55:09 -0600 (MDT) Content-Type: text/plain; charset="iso-8859-1" From: Aaron D.Gifford To: freebsd-mailing-lists@freebsd.org Subject: IP fragment DOS attack on FreeBSD question Date: Mon, 6 Aug 2001 16:55:08 -0600 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <01080616550800.31114@eq.net> 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 The recent FreeBSD advisory regarding IP fragment denial-of-service attacks didn't mention whether or not an IP filter (ipfw or ipf) that drops all fragments is an adequate temporary work-around or not. Does anyone who is familiar with the problem and attack know if something like the following would be a useful temporary work-around? ipfw add 1 deny ip from any to any fragment Does the above drop the fragment and prevent reassembly buffer starvation? Of course dropping ALL fragments like that will limit the connectivity of the host to hosts and networks where fragmentation occurs. But, if the above DOES prevent the DOS, it may be a useful tradeoff to use it as a temporary work-around until kernels are patched (kernels with ipfw already enabled). Aaron out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 16: 6:14 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10]) by hub.freebsd.org (Postfix) with ESMTP id 04BC237B443 for ; Mon, 6 Aug 2001 16:06:05 -0700 (PDT) (envelope-from agifford@infowest.com) Received: from eq.net (eq.net [208.186.104.163]) by ns1.infowest.com (Postfix) with SMTP id 836B9211DE for ; Mon, 6 Aug 2001 17:06:00 -0600 (MDT) Content-Type: text/plain; charset="iso-8859-1" From: Aaron D.Gifford To: freebsd-security@freebsd.org Subject: Re: ssh keepalive and dynamic rules Date: Mon, 6 Aug 2001 17:06:00 -0600 X-Mailer: KMail [version 1.2] Organization: InfoWest, Inc. MIME-Version: 1.0 Message-Id: <01080617060001.31114@eq.net> Content-Transfer-Encoding: 8bit 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 08/06/2001 at 09:28:32 Fernando Schapachnik wrote: > >Hello, > On a bridging firewall using ipfw I noticed that ssh >conections get hung after an inactivity period. > > On some tests, tcpdumping the connection between two FreeBSD >machines, both client and server with ssh "KeepAlive yes", I don't >see any kind of keep alive traffic. > > dyn_ack timeout could be raised, but doesn't seem a proper >solution. > > Any ideas on why ssh is not sending keepalive packets? > > Thanks! > > >Fernando P. Schapachnik >Planificación de red y tecnología >VIA NET.WORKS ARGENTINA S.A. <> An alternative is to use a patch to ipfw that lets you override the dyn_ack timeout on a per-rule basis. For example: ...ipfw rules here... ipfw add check-state ...ipfw rules here... # Give SSH TCP sessions (port 22) a 4-hour dynamic rule lifetime: ipfw add pass tcp from any to me 22 in setup keep-state lifetime 7200 ...ipfw rules here... I've posted my patch to add this functionality to ipfw to various lists before. I also submitted it as a PR in hopes that the ipfw maintainer would incorporate the feature into ipfw, but the maintainer (as I understand it) doesn't think per-rule lifetime control is a valuable feature (I believe he recommends just setting the global dyn_ack sysctl setting large enough). If enough people actually find this feature useful, I would hope the maintainer could be persuaded to change his mind. For more information, or to get a copy of the patch, check out the following still-open PR (it contains both the patch, the maintainer's reasoning, and my response): http://www.freebsd.org/cgi/query-pr.cgi?pr=28713 Or visit my personal web site where copies of the patch can be downloaded: http://www.aarongifford.com/computers/ipfwpatch.html As always, I'm interested in hearing from anyone who uses the patch. Aaron out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Aug 6 23:21:48 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id 5A74737B403 for ; Mon, 6 Aug 2001 23:21:43 -0700 (PDT) (envelope-from poige@morning.ru) Received: from NIC1 ([195.161.98.236]) by ns.morning.ru (8.11.5/8.11.5) with ESMTP id f776LSE51896; Tue, 7 Aug 2001 14:21:28 +0800 (KRAST) Date: Tue, 7 Aug 2001 14:21:41 +0800 From: Igor Podlesny X-Mailer: The Bat! (v1.52 Beta/7) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 3 (Normal) Message-ID: <261958205.20010807142141@morning.ru> To: Alexey Zakirov Cc: Paulo Fragoso , security@FreeBSD.ORG Subject: Re[3]: SSHD in JAIL In-Reply-To: References: MIME-Version: 1.0 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 a cite from MAN: Inside the prison, the concept of "superuser" is very diluted. In gen- eral, it can be assumed that nothing can be mangled from inside a prison which does not exist entirely inside that prison. For instance the directory tree below ``path'' can be manipulated all the ways a root can normally do it, including ``rm -rf /*'' but new device special nodes can- not be created because they reference shared resources (the device drivers in the kernel). so it's becoming too redundant to use nodev with jail(2), don't you agree? > On Mon, 6 Aug 2001, Paulo Fragoso wrote: >> I was thinking if jail dir mounted on file system with "nodev" it will >> more secure. Anyone colud acess any disks in the jails enviroment. Is it >> all right? > yes, but you don't have to create all those disk device nodes. And of > course you can't create a device node inside jail itself. > *** WBR, Alexey Zakirov (frank@agava.com) -- Igor mailto:poige@morning.ru http://morning.ru/~poige To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 4:55:44 2001 Delivered-To: freebsd-security@freebsd.org Received: from mirage.nlink.com.br (unknown [200.249.195.3]) by hub.freebsd.org (Postfix) with SMTP id A880137B405 for ; Tue, 7 Aug 2001 04:55:33 -0700 (PDT) (envelope-from paulo@nlink.com.br) Received: (qmail 33215 invoked by uid 501); 7 Aug 2001 11:55:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Aug 2001 11:55:27 -0000 Date: Tue, 7 Aug 2001 08:55:27 -0300 (BRT) From: Paulo Fragoso To: Igor Podlesny Cc: Alexey Zakirov , Subject: Re[3]: SSHD in JAIL In-Reply-To: <261958205.20010807142141@morning.ru> Message-ID: <20010807085156.F29899-100000@mirage.nlink.com.br> 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 On Tue, 7 Aug 2001, Igor Podlesny wrote: > > a cite from MAN: > Inside the prison, the concept of "superuser" is very diluted. In gen- > eral, it can be assumed that nothing can be mangled from inside a prison > which does not exist entirely inside that prison. For instance the > directory tree below ``path'' can be manipulated all the ways a root can > normally do it, including ``rm -rf /*'' but new device special nodes can- > not be created because they reference shared resources (the device > drivers in the kernel). > > so it's becoming too redundant to use nodev with jail(2), don't you > agree? Yes, I agree. Thanks, Paulo Fragoso. > > > On Mon, 6 Aug 2001, Paulo Fragoso wrote: > > >> I was thinking if jail dir mounted on file system with "nodev" it will > >> more secure. Anyone colud acess any disks in the jails enviroment. Is it > >> all right? > > > yes, but you don't have to create all those disk device nodes. And of > > course you can't create a device node inside jail itself. > > > *** WBR, Alexey Zakirov (frank@agava.com) > > -- > Igor mailto:poige@morning.ru > http://morning.ru/~poige > > -- __O _-\<,_ Why drive when you can bike? (_)/ (_) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 4:56:28 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id AD46837B40A for ; Tue, 7 Aug 2001 04:56:22 -0700 (PDT) (envelope-from fschapachnik@vianetworks.com.ar) Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.9.3/8.9.3) id IAA80678; Tue, 7 Aug 2001 08:55:16 -0300 (ART) X-Authentication-Warning: ns1.via-net-works.net.ar: fpscha set sender to fschapachnik@vianetworks.com.ar using -f Date: Tue, 7 Aug 2001 08:55:16 -0300 From: Fernando Schapachnik To: "Aaron D.Gifford" Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh keepalive and dynamic rules Message-ID: <20010807085516.A78351@ns1.via-net-works.net.ar> References: <01080617060001.31114@eq.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <01080617060001.31114@eq.net>; from agifford@infowest.com on Mon, Aug 06, 2001 at 05:06:00PM -0600 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 En un mensaje anterior, Aaron D.Gifford escribió: [...] > As always, I'm interested in hearing from anyone who uses the patch. Thanks for the info! I do think that rule-dependant lifetime is a usefull feature. The machine in question is tracking RELENG_4_3, so I want to keep it as standard as possible. As the ssh conections are only allowed from a bunch of trusted hosts I replaced the 'setup keep-state' rule for a static rule and now all is fine. Thanks for your help! Fernando P. Schapachnik Planificación de red y tecnología VIA NET.WORKS ARGENTINA S.A. fschapachnik@vianetworks.com.ar Tel.: (54-11) 4323-3381 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 7:13:51 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.roe35.lth2.k12.il.us (unknown [209.175.240.58]) by hub.freebsd.org (Postfix) with ESMTP id 0404F37B405 for ; Tue, 7 Aug 2001 07:13:47 -0700 (PDT) (envelope-from dallen@roe35.lth2.k12.il.us) Received: from dougs_laptop (dougs_laptop [209.175.240.20]) by mail.roe35.lth2.k12.il.us (8.9.3/8.9.3) with ESMTP id JAA41985 for ; Tue, 7 Aug 2001 09:17:54 -0500 (CDT) (envelope-from dallen@roe35.lth2.k12.il.us) Message-ID: <200108070919280409.008598DB@mail.roe35.lth2.k12.il.us> References: <200108070719460362.001801FC@mail.roe35.lth2.k12.il.us> X-Mailer: Calypso Version 3.00.01.02 (1) Date: Tue, 07 Aug 2001 09:19:28 -0500 From: "Douglas G. Allen" To: freebsd-security@freebsd.org Subject: ipfw question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 a network card in a 4.3-Release + security fixes, with two IP= addresses assigned to the card. fxp0 and the fxp0_alias are both running.= I ipfw (in a client configuration) using the IP's for both of these (or= just fxp0 for that matter) and the regular netmask (255.255.255.192).= fxp0's IP works just like I would expect, but the IP address assigned to= fxp0_alias is unreachable and can't get out to the network. Does anyone= have any suggestions or tricks on how I can get the ipfw rules to work on= both interfaces?? The ifconfig's are set up so that fxp0 is IP a.b.c.d netmask= 255.255.255.192 and fxp0_alias is a.b.c.e netmask 255.255.255.255. Thanks, in advance, for any information you can provide. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 7:27:39 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id D468637B40B for ; Tue, 7 Aug 2001 07:27:35 -0700 (PDT) (envelope-from fschapachnik@vianetworks.com.ar) Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.9.3/8.9.3) id LAA96229; Tue, 7 Aug 2001 11:26:10 -0300 (ART) X-Authentication-Warning: ns1.via-net-works.net.ar: fpscha set sender to fschapachnik@vianetworks.com.ar using -f Date: Tue, 7 Aug 2001 11:26:10 -0300 From: Fernando Schapachnik To: "Douglas G. Allen" Cc: freebsd-security@FreeBSD.ORG Subject: Re: ipfw question Message-ID: <20010807112610.H34971@ns1.via-net-works.net.ar> References: <200108070719460362.001801FC@mail.roe35.lth2.k12.il.us> <200108070919280409.008598DB@mail.roe35.lth2.k12.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <200108070919280409.008598DB@mail.roe35.lth2.k12.il.us>; from dallen@roe35.lth2.k12.il.us on Tue, Aug 07, 2001 at 09:19:28AM -0500 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 En un mensaje anterior, Douglas G. Allen escribió: [...] > The ifconfig's are set up so that fxp0 is IP a.b.c.d netmask > 255.255.255.192 and fxp0_alias is a.b.c.e netmask 255.255.255.255. 255.255.255.255 is an invalid netmask (I don't even know why ifconfig didn't rejected it). It should have the same netmask of the fxp0 interface if what you mean is to have a machine with two IPs on the same network. Regards. Fernando P. Schapachnik Planificación de red y tecnología VIA NET.WORKS ARGENTINA S.A. fschapachnik@vianetworks.com.ar Tel.: (54-11) 4323-3381 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 7:33:56 2001 Delivered-To: freebsd-security@freebsd.org Received: from poontang.schulte.org (poontang.schulte.org [209.134.156.197]) by hub.freebsd.org (Postfix) with ESMTP id 0CE7E37B401 for ; Tue, 7 Aug 2001 07:33:51 -0700 (PDT) (envelope-from christopher@schulte.org) Received: from schulte-laptop.schulte.org (nb-65.netbriefings.com [209.134.134.65]) by poontang.schulte.org (Postfix) with ESMTP id 0E8B4D149E; Tue, 7 Aug 2001 09:33:41 -0500 (CDT) Message-Id: <5.1.0.14.0.20010807093229.03c3eda0@pop.schulte.org> X-Sender: schulte@pop.schulte.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 07 Aug 2001 09:33:20 -0500 To: Fernando Schapachnik , "Douglas G. Allen" From: Christopher Schulte Subject: Re: ipfw question Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <20010807112610.H34971@ns1.via-net-works.net.ar> References: <200108070919280409.008598DB@mail.roe35.lth2.k12.il.us> <200108070719460362.001801FC@mail.roe35.lth2.k12.il.us> <200108070919280409.008598DB@mail.roe35.lth2.k12.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable 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 11:26 AM 8/7/2001 -0300, Fernando Schapachnik wrote: >En un mensaje anterior, Douglas G. Allen escribi=F3: >[...] > > The ifconfig's are set up so that fxp0 is IP a.b.c.d netmask > > 255.255.255.192 and fxp0_alias is a.b.c.e netmask 255.255.255.255. > >255.255.255.255 is an invalid netmask (I don't even know why ifconfig >didn't rejected it). It should have the same netmask of the fxp0 >interface if what you mean is to have a machine with two IPs on the >same network. Not true;=20 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-virtu= al-hosts.html 'The calculation of alias netmasks is important, but fortunately quite=20 simple. For a given interface, there must be one address which correctly=20 represents the network's netmask. Any other addresses which fall within=20 this network must have a netmask of all 1's.' >Regards. > > >Fernando P. Schapachnik >Planificaci=F3n de red y tecnolog=EDa >VIA NET.WORKS ARGENTINA S.A. >fschapachnik@vianetworks.com.ar >Tel.: (54-11) 4323-3381 -c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 7:42:44 2001 Delivered-To: freebsd-security@freebsd.org Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by hub.freebsd.org (Postfix) with ESMTP id C5E9F37B405 for ; Tue, 7 Aug 2001 07:42:39 -0700 (PDT) (envelope-from d.m.pick@qmw.ac.uk) Received: from xi.css.qmw.ac.uk ([138.37.8.11]) by zeta.qmw.ac.uk with esmtp (Exim 3.16 #1) id 15U83p-0004kz-00; Tue, 07 Aug 2001 15:42:21 +0100 Received: from cgaa180 by xi.css.qmw.ac.uk with local (Exim 1.92 #1) id 15U83q-0005IG-00; Tue, 7 Aug 2001 15:42:22 +0100 X-Mailer: exmh version 2.0.2 2/24/98 To: Fernando Schapachnik Cc: "Douglas G. Allen" , freebsd-security@FreeBSD.ORG Subject: Re: ipfw question In-reply-to: Your message of "Tue, 07 Aug 2001 11:26:10 -0300." <20010807112610.H34971@ns1.via-net-works.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 07 Aug 2001 15:42:22 +0100 From: David Pick Message-Id: 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 > > The ifconfig's are set up so that fxp0 is IP a.b.c.d netmask > > 255.255.255.192 and fxp0_alias is a.b.c.e netmask 255.255.255.255. > = > 255.255.255.255 is an invalid netmask (I don't even know why ifconfig > didn't rejected it). Not so - I've used it successfully. > It should have the same netmask of the fxp0 > interface if what you mean is to have a machine with two IPs on the > same network. However, *if* the two IP addresses are within the same subnet, then I do agree with you that they should have the same netmask. And should be on the same interface! Since the subnet mask in this case is 255.255.255.192 it isn't clear from the "a.b.c.d" and "a.b.c.e" if the two addresses are in the same subnet or different but close subnets. -- = David Pick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 7:46:53 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id 3366437B405 for ; Tue, 7 Aug 2001 07:46:49 -0700 (PDT) (envelope-from fschapachnik@vianetworks.com.ar) Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.9.3/8.9.3) id LAA13980; Tue, 7 Aug 2001 11:45:20 -0300 (ART) X-Authentication-Warning: ns1.via-net-works.net.ar: fpscha set sender to fschapachnik@vianetworks.com.ar using -f Date: Tue, 7 Aug 2001 11:45:20 -0300 From: Fernando Schapachnik To: Christopher Schulte Cc: "Douglas G. Allen" , freebsd-security@FreeBSD.ORG Subject: Re: ipfw question Message-ID: <20010807114520.A12811@ns1.via-net-works.net.ar> References: <200108070919280409.008598DB@mail.roe35.lth2.k12.il.us> <200108070719460362.001801FC@mail.roe35.lth2.k12.il.us> <200108070919280409.008598DB@mail.roe35.lth2.k12.il.us> <20010807112610.H34971@ns1.via-net-works.net.ar> <5.1.0.14.0.20010807093229.03c3eda0@pop.schulte.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010807093229.03c3eda0@pop.schulte.org>; from christopher@schulte.org on Tue, Aug 07, 2001 at 09:33:20AM -0500 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 En un mensaje anterior, Christopher Schulte escribió: [...] > 'The calculation of alias netmasks is important, but fortunately quite > simple. For a given interface, there must be one address which correctly > represents the network's netmask. Any other addresses which fall within > this network must have a netmask of all 1's.' You learn something every day :) Any way, I used it the other way plenty of times with hundreds of virtual hosts. Regards. Fernando P. Schapachnik Planificación de red y tecnología VIA NET.WORKS ARGENTINA S.A. fschapachnik@vianetworks.com.ar Tel.: (54-11) 4323-3381 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 8:26: 4 2001 Delivered-To: freebsd-security@freebsd.org Received: from mufasa.swistgroup.com (unknown [64.245.10.163]) by hub.freebsd.org (Postfix) with ESMTP id E472937B403 for ; Tue, 7 Aug 2001 08:25:58 -0700 (PDT) (envelope-from max.clements@swistgroup.com) Received: from timon.swistgroup.com ([172.16.1.30]) by mufasa.swistgroup.com with esmtp (Exim 3.22 #1) id 15U8jI-0004SO-00; Tue, 07 Aug 2001 17:25:12 +0200 Received: from steinmail.swistgroup.com ([192.168.200.112]) by timon.swistgroup.com with esmtp (Exim 3.22 #4) id 15U8jX-000B0x-00; Tue, 07 Aug 2001 17:25:27 +0200 Content-Class: urn:content-classes:message Subject: RE: ipfw question MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Aug 2001 17:25:37 +0200 Disposition-Notification-To: "Max Clements" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ipfw question Thread-Index: AcEfUwePea1lGho7Rsy/BHocR2jtZAAAZokw From: "Max Clements" To: "Fernando Schapachnik" Cc: 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 > En un mensaje anterior, Douglas G. Allen escribi=F3: > [...] > > The ifconfig's are set up so that fxp0 is IP a.b.c.d netmask > > 255.255.255.192 and fxp0_alias is a.b.c.e netmask 255.255.255.255. >=20 > 255.255.255.255 is an invalid netmask (I don't even know why ifconfig > didn't rejected it). It should have the same netmask of the fxp0 Nope - it is the netmask that you associate with one host... ifconfig is quite corrent in NOT rejecting it as it is right to use it = with an alias... > interface if what you mean is to have a machine with two IPs on the = same network. Nope an alias that is on the same IP segment as the main interface must = have a netmask of all ones, i.e., 255.255.255.255 or of you like that in hex 0xffffffff. Please refer to the FreeBSD /etc/defaults/rc.conf file and = see: -- #ifconfig_lo0_alias0=3D"inet 127.0.0.254 netmask 0xffffffff" # Sample = alias entry. -- Have fun... Max Clements Systems Specialist (Billing) Vodacom SA - Monday is an awfull way to spend 1/7th of your life To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 8:35:43 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.roe35.lth2.k12.il.us (unknown [209.175.240.58]) by hub.freebsd.org (Postfix) with ESMTP id 3E84437B403 for ; Tue, 7 Aug 2001 08:35:40 -0700 (PDT) (envelope-from dallen@roe35.lth2.k12.il.us) Received: from dougs_laptop (dougs_laptop [209.175.240.20]) by mail.roe35.lth2.k12.il.us (8.9.3/8.9.3) with ESMTP id KAA42625; Tue, 7 Aug 2001 10:39:10 -0500 (CDT) (envelope-from dallen@roe35.lth2.k12.il.us) Message-ID: <200108071040440170.00CFFECC@mail.roe35.lth2.k12.il.us> In-Reply-To: References: X-Mailer: Calypso Version 3.00.01.02 (1) Date: Tue, 07 Aug 2001 10:40:44 -0500 From: "Douglas G. Allen" To: "David Pick" Cc: freebsd-security@FreeBSD.ORG Subject: Re: ipfw question Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable 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 David, >However, *if* the two IP addresses are within the same subnet, then >I do agree with you that they should have the same netmask. And should >be on the same interface! Since the subnet mask in this case is >255.255.255.192 it isn't clear from the "a.b.c.d" and "a.b.c.e" if >the two addresses are in the same subnet or different but close >subnets. Both IP addresses are within the same subnet and are intended to be within= the same subnet. In this instance, once everything is moved around and= loaded, d=3D60, e=3D43. What it sounds like to me is that I need to set= the netmask on the alias to 255.255.255.192 and then have a set of= firewall rules for the true IP and the alias. Does this sufficiently= clarify things? I was under the impression that the alias had to have a= mask of 255.255.255.255 in order to work correctly. Is my impression in= error?? Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 8:45: 7 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.roe35.lth2.k12.il.us (unknown [209.175.240.58]) by hub.freebsd.org (Postfix) with ESMTP id 8FA8437B401 for ; Tue, 7 Aug 2001 08:45:04 -0700 (PDT) (envelope-from dallen@roe35.lth2.k12.il.us) Received: from dougs_laptop (dougs_laptop [209.175.240.20]) by mail.roe35.lth2.k12.il.us (8.9.3/8.9.3) with ESMTP id KAA42759; Tue, 7 Aug 2001 10:49:03 -0500 (CDT) (envelope-from dallen@roe35.lth2.k12.il.us) Message-ID: <200108071050370603.00D90CE5@mail.roe35.lth2.k12.il.us> In-Reply-To: References: X-Mailer: Calypso Version 3.00.01.02 (1) Date: Tue, 07 Aug 2001 10:50:37 -0500 From: "Douglas G. Allen" To: "Max Clements" Cc: freebsd-security@freebsd.org Subject: RE: ipfw question Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable 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 Max, >Nope - it is the netmask that you associate with one host... >ifconfig is quite corrent in NOT rejecting it as it is right to use it= with >an alias... My understanding, based upon a lot of reading and some discussions on= Sunday in stable, was that only the first IP address was given the true= network mask. The aliases had to be given the 255.255.255.255 netmask in= order for it to work. Otherwise arp might complain, as it did with two= cards active on the machine. >Nope an alias that is on the same IP segment as the main interface must= have >a netmask of all ones, i.e., 255.255.255.255 or of you like that in hex >0xffffffff. Please refer to the FreeBSD /etc/defaults/rc.conf file and= see: >-- >#ifconfig_lo0_alias0=3D"inet 127.0.0.254 netmask 0xffffffff" # Sample= alias >entry. >-- Ok, that backs up my interpretation above. Now, how do I get ipfw to allow= me to write rules that will filter on both rules and leave both the true= address and the alias active and able to see the network? I've tried firewalling just the true address, firewalling both addresses= with the true netmask, firewalling the true address with the actual mask= and the alias with 255.255.255.255. In each case, I could get the true= address see the network and the ipfw rules worked as expected. However= the alias didn't function in each case. Any suggestions? Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 8:51:56 2001 Delivered-To: freebsd-security@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 453F937B40A for ; Tue, 7 Aug 2001 08:51:49 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 743 invoked by uid 1000); 7 Aug 2001 15:50:37 -0000 Date: Tue, 7 Aug 2001 18:50:37 +0300 From: Peter Pentchev To: "Douglas G. Allen" Cc: Max Clements , freebsd-security@freebsd.org Subject: Re: ipfw question Message-ID: <20010807185037.B495@ringworld.oblivion.bg> Mail-Followup-To: "Douglas G. Allen" , Max Clements , freebsd-security@freebsd.org References: <200108071050370603.00D90CE5@mail.roe35.lth2.k12.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108071050370603.00D90CE5@mail.roe35.lth2.k12.il.us>; from dallen@roe35.lth2.k12.il.us on Tue, Aug 07, 2001 at 10:50:37AM -0500 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 Tue, Aug 07, 2001 at 10:50:37AM -0500, Douglas G. Allen wrote: > Max, > > >Nope - it is the netmask that you associate with one host... > >ifconfig is quite corrent in NOT rejecting it as it is right to use it with > >an alias... > > My understanding, based upon a lot of reading and some discussions on Sunday in stable, was that only the first IP address was given the true network mask. The aliases had to be given the 255.255.255.255 netmask in order for it to work. Otherwise arp might complain, as it did with two cards active on the machine. Absolutely correct. The alias should be defined with an all 1's netmask. > >Nope an alias that is on the same IP segment as the main interface must have > >a netmask of all ones, i.e., 255.255.255.255 or of you like that in hex > >0xffffffff. Please refer to the FreeBSD /etc/defaults/rc.conf file and see: > >-- > >#ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0xffffffff" # Sample alias > >entry. > >-- > > Ok, that backs up my interpretation above. Now, how do I get ipfw to allow me to write rules that will filter on both rules and leave both the true address and the alias active and able to see the network? > > I've tried firewalling just the true address, firewalling both addresses with the true netmask, firewalling the true address with the actual mask and the alias with 255.255.255.255. In each case, I could get the true address see the network and the ipfw rules worked as expected. However the alias didn't function in each case. Any suggestions? I don't think the 'client' firewall rules per se are supposed to work for more than one IP address. You'll need to take them as a base, and write up your own firewall script. G'luck, Peter -- I am jealous of the first word in this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 9:17: 3 2001 Delivered-To: freebsd-security@freebsd.org Received: from n20.groups.yahoo.com (n20.groups.yahoo.com [216.115.96.70]) by hub.freebsd.org (Postfix) with SMTP id 69EA837B412 for ; Tue, 7 Aug 2001 09:15:34 -0700 (PDT) (envelope-from notify-return-freebsd-security=freebsd.org@egroups.co.uk) X-eGroups-Return: notify-return-freebsd-security=freebsd.org@egroups.co.uk Received: from [10.1.10.141] by c9.egroups.com with NNFMP; 07 Aug 2001 16:15:32 -0000 Date: 7 Aug 2001 16:15:28 -0000 Message-ID: <997200928.5289.12669.f8@egroups.co.uk> From: freebsd-lists-for-dayan-only Moderator Reply-To: freebsd-lists-for-dayan-only-unsubscribe@egroups.co.uk To: freebsd-security@freebsd.org Subject: Welcome to the freebsd-lists-for-dayan-only group MIME-Version: 1.0 Content-Type: text/plain 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 Hello, I've added you to my freebsd-lists-for-dayan-only group at eGroups, a free, easy-to-use email group service. As a member of this group, you may send messages to the entire group using just one email address: freebsd-lists-for-dayan-only@egroups.co.uk. eGroups also makes it easy to store photos and files, coordinate events, and more. Here's a description of the group: ------------------------------------------------------------------------ This list is subscribed to various FreeBSD lists only for Dayan. ------------------------------------------------------------------------ Here's my introductory message for you: ------------------------------------------------------------------------ Hello, Welcome to the freebsd-lists-for-dayan-only group at eGroups, a free, easy-to-use email group service. Please take a moment to review this message. To start sending messages to members of this group, simply send email to freebsd-lists-for-dayan-only@egroups.co.uk If you do not wish to belong to freebsd-lists-for-dayan-only, you may unsubscribe by sending an email to freebsd-lists-for-dayan-only-unsubscribe@egroups.co.uk You may also visit the eGroups web site to modify your subscriptions: http://www.egroups.co.uk/mygroups Regards, Moderator, freebsd-lists-for-dayan-only ------------------------------------------------------------------------ TO START SENDING messages to members of this group, simply send email to freebsd-lists-for-dayan-only@egroups.co.uk If you do not wish to belong to the freebsd-lists-for-dayan-only group, you can unsubscribe by replying to this message, or by sending an email to freebsd-lists-for-dayan-only-unsubscribe@egroups.co.uk Regards, Moderator, freebsd-lists-for-dayan-only SPECIAL NOTE FROM eGroups: Because eGroups values your privacy, it is a violation of our service rules for moderators to add subscribers to a group against their wishes. If you feel this has happened, please notify us at abuse@egroups.co.uk P.S. If you would like to learn more about the freebsd-lists-for-dayan-only group, please visit http://www.egroups.co.uk/group/freebsd-lists-for-dayan-only and enter the following sign-in information: Email address: freebsd-security@freebsd.org Password: obseukqcwpmdsga This password has been randomly generated for you. Once you have signed in, you should change your password by visiting http://www.egroups.co.uk/myprofile To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 9:39: 9 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.roe35.lth2.k12.il.us (unknown [209.175.240.58]) by hub.freebsd.org (Postfix) with ESMTP id E969E37B406 for ; Tue, 7 Aug 2001 09:39:04 -0700 (PDT) (envelope-from dallen@roe35.lth2.k12.il.us) Received: from dougs_laptop (dougs_laptop [209.175.240.20]) by mail.roe35.lth2.k12.il.us (8.9.3/8.9.3) with ESMTP id LAA43336; Tue, 7 Aug 2001 11:43:07 -0500 (CDT) (envelope-from dallen@roe35.lth2.k12.il.us) Message-ID: <200108071144420009.010A8E5B@mail.roe35.lth2.k12.il.us> In-Reply-To: <20010807185037.B495@ringworld.oblivion.bg> References: <200108071050370603.00D90CE5@mail.roe35.lth2.k12.il.us> <20010807185037.B495@ringworld.oblivion.bg> X-Mailer: Calypso Version 3.00.01.02 (1) Date: Tue, 07 Aug 2001 11:44:42 -0500 From: "Douglas G. Allen" To: "Peter Pentchev" Cc: freebsd-security@freebsd.org Subject: Re: ipfw question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 Peter, >I don't think the 'client' firewall rules per se are supposed to work >for more than one IP address. You'll need to take them as a base, and >write up your own firewall script. I added several sets of rules and had rules for the network, the true= address, and the alias. The network and regular address rules worked, but= the alias rules didn't. I could just drop the rules into another file and have it called during= boot. I just figured that since rc.firewall got called anyway, I'd use= what was already provided and try to avoid reinventing the wheel. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 10: 7:43 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.roe35.lth2.k12.il.us (unknown [209.175.240.58]) by hub.freebsd.org (Postfix) with ESMTP id 21B8937B409 for ; Tue, 7 Aug 2001 10:07:37 -0700 (PDT) (envelope-from dallen@roe35.lth2.k12.il.us) Received: from dougs_laptop (dougs_laptop [209.175.240.20]) by mail.roe35.lth2.k12.il.us (8.9.3/8.9.3) with ESMTP id MAA43627; Tue, 7 Aug 2001 12:11:36 -0500 (CDT) (envelope-from dallen@roe35.lth2.k12.il.us) Message-ID: <200108071213090935.01249DF0@mail.roe35.lth2.k12.il.us> In-Reply-To: References: X-Mailer: Calypso Version 3.00.01.02 (1) Date: Tue, 07 Aug 2001 12:13:09 -0500 From: "Douglas G. Allen" To: "Max Clements" Cc: freebsd-security@freebsd.org Subject: RE: ipfw question Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable 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 Max, >I am assuming you mean on both interfaces, on my machine i use aliases as >well with the port-redirect statement to natd, and I set the IPFW rules up >using the via rl0 (my external) interface format. I want to use ipfw to filter on both the true interface (fxp0) and the= alias. I'm not using NAT at all. I'm using public addresses. >I must confess, I have battled with the same problem - and I have not= managed >to get the functioning of IPFW and NATD clear in my head, what I do know= is >that IPFW uses divert(4) sockets to divert all ip traffic to NATD *before*= it >processes any rules. This means that all ipfw rules that you use in your >firewall should refer to the translated addresses and not the public >addresses, as natd rewrites the packets after the divert and then hands= them >back to ipfw at the rule number following the divert rule. To illustrate= my >point , here are thefirst few rules from my firewall > >[46] root@mufasa:/usr/local# ipfw list >00050 divert 8668 ip from any to any via rl0 >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 >00400 deny log logamount 100 ip from 172.16.0.10 to any via rl0 >00500 deny log logamount 100 ip from 192.168.0.0/16 to any via rl0 If I were using natd, I understand that I have to use the translated= addresses. Maybe I do need to look at the alias as a translation and use= the via fxp0 in the rules. I haven't done so up to this point, because I= hoped to have a set of rules with two real interfaces. That got changed= to two IP's on one interface. At any rate, it's given me something else= to think about and try. >NATD hands packets back at rule 100 after translation, this translation is >performed on all the alias addresses according to the nat config. This I think I understand, because the translation occurs before the rules= are tested. >Hope this helps, as it was something that really tripped me up until I >started to log ALL packets - which was a daunting task... Now that I see it, I think it needs to have the via clause on the rules for= the alias, since it is going through the real interface. The best thing I= can think of is to go try it and see if it works. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 14: 9:46 2001 Delivered-To: freebsd-security@freebsd.org Received: from lariat.org (lariat.org [12.23.109.2]) by hub.freebsd.org (Postfix) with ESMTP id B41E037B505 for ; Tue, 7 Aug 2001 14:08:32 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.org [12.23.109.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id PAA03167; Tue, 7 Aug 2001 15:08:03 -0600 (MDT) Message-Id: <4.3.2.7.2.20010807134456.049034f0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 13:53:42 -0600 To: Fernando Schapachnik , "Douglas G. Allen" From: Brett Glass Subject: Re: ipfw question Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <20010807112610.H34971@ns1.via-net-works.net.ar> References: <200108070919280409.008598DB@mail.roe35.lth2.k12.il.us> <200108070719460362.001801FC@mail.roe35.lth2.k12.il.us> <200108070919280409.008598DB@mail.roe35.lth2.k12.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 08:26 AM 8/7/2001, Fernando Schapachnik wrote: >En un mensaje anterior, Douglas G. Allen escribió: >[...] >> The ifconfig's are set up so that fxp0 is IP a.b.c.d netmask >> 255.255.255.192 and fxp0_alias is a.b.c.e netmask 255.255.255.255. > >255.255.255.255 is an invalid netmask (I don't even know why ifconfig >didn't rejected it). Not correct. A netmask of all 1's is legal; it effectively establishes a "host route" within the machine so that outbound packets are delivered to that interface as efficiently as possible. Remember that the internal routing table in a TCP/IP stack is laid out (and is searched) from specific to general, with the default route being the most general (it has a mask of all zeroes). Host routes, because they are the most specific routes possible, are checked first. Using the netmask of the overlaid network won't necessarily cause things to fail (it depends upon what else is in the routing table), but will slow things down. By the way, this is really OT for this list because it doesn't involve security. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 21: 9:48 2001 Delivered-To: freebsd-security@freebsd.org Received: from new.now.nxt.cn (unknown [61.143.52.235]) by hub.freebsd.org (Postfix) with SMTP id C509537B403 for ; Tue, 7 Aug 2001 21:09:40 -0700 (PDT) (envelope-from root@now.nxt.cn) Received: (qmail 28025 invoked by uid 99); 9 Mar 2001 13:35:00 -0000 Date: 9 Mar 2001 13:35:00 -0000 Message-ID: <20010309133500.28024.qmail@new.now.nxt.cn> To: freebsd-security@freebsd.org Subject: ¡îÓòÃû×¢²á¿Õ¼äÉêÇë¸÷ËÍÈý¸ö´Î¼¶ÓòÃû»¹Ãâ·ÑÊÔÓÃ! From: "ÍøÂçʱ´ú" Reply-To: youko@now.net.cn 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 ×ð¾´µÄÅóÓÑ£¬ÄúºÃ£¡ ·Ç³£¸ÐлÄúµÄä¯ÀÀ£¬Èç¹ûÄúÕýΪѰÕÒÒ»¸ö¸üºÃµÄISP¶ø·³ÄÕ£¬ÄÇôÎÒÃÇÍøÂçʱ´úhttp://www.now.net.cnΪÄúÌṩÁË×î¼ÑµÄÑ¡Ôñ£¡ ¡î ÓòÃû×¢²á ×¢²áÓòÃûÔùËÍ3¸ö´Î¼¶ÓòÃû(´øVDNS)£¡ ͬʱÉêÇë¿Õ¼äÔÙÔùËÍ3¸ö´Î¼¶ÓòÃû£¡ ¡îÐéÄâÖ÷»ú Ò» ÌضàÓÅ»Ý ·²ÔÚ8.1µ½9.1×¢²áÓòÃûͬʱÉêÇë¿Õ¼äËÍ6¸ö´Î¼¶ÓòÃû£¡µÈÓÚÒ»¸öÓòÃû¾ÍÄÜͬʱ½¨6¸öÍøÕ¾£¡Í¬Ê±¼ÓËÍ15¸öÉÌÓÃÓʼþÕ˺ţ¡ ¶þ ³¬µÍÌØ¼Û 280Ôª£¡Äú¿ÉÒÔÁ¢¿ÌÓµÓÐÎȶ¨¶ø¿ìËÙµÄ100MÐéÄâÖ÷»ú¿Õ¼ä!»¹ÓÌԥʲôÄØ£¬¸Ï¿ìÐж¯°É£¡ Èý ³¹µ×½â·Å ÏÖÔÚÌ컥¿Æ¼¼µÄASPºÍACCESSÊý¾Ý¿âÈ«Ã濪·Å£¬Ö»Ðè100Ôª¾ÍÈÃÄúµÄÍøÕ¾ÓµÓÐÊý¾Ý¿â¡£ ²¢ÓÐÌṩCGI PERL PHP JSP µÈÒ»Ìå¸ß¼¶¿Õ¼ä.ËùÓпռäʵʱ¿ªÍ¨Ãâ·ÑÊÔÓÃ15Ìì! ¡î¡î"»ðºìÏÄÈÕ¡±Ö÷»úÍйÜÓÅ»Ýì«·çÈ«ÃæµÇ½£¬Ç¿´ó¡¢¸ß±ê×¼µÄµçÐż¶Êý¾ÝÖÐÐÄ»ú·¿£¬¸ß°²È«ÌØÐÔ¡¢¸ß·þÎñ±ê×¼¡¢ ÔÙ¼ÓÉϺÏÀíµÄ¼Û¸ñ£¬Ïò¹ã´ó¿Í»§Ìṩ¸ßÐԼ۱ȵķþÎñ¡£Ïê¼ûhttp://idc.now.net.cn ¡î¡îͬʱÎÒÃÇÏò¹ã´ó¸÷½ì³ÏÕ÷´úÀí£¬ÈȳÀÑûÇëÄú¼ÓÈëÍøÂçʱ´úµÄÒµÎñºÏ×÷ÕóÓª£¬¹²Í¬·ÖÏíÍøÂçʱ´úµÄÅÓ´ó¿Í»§×ÊÔ´¡£ÏêϸÇë·ÃÎÊÎÒÃÇÍøÕ¾¡£ »òÖ±½ÓÁªÏµÎÒÃÇ: ÇñС½ã michelle@now.net.cn ÁÖÏÈÉú youko@now.net.cn¡¡¡¡¡¡ µç»°£º0756-2125583 22216376 ¼¼Êõ²¿£º sanry@now.net.cn youko@now.net.cn 0756--2216376 2139739 »¶Ó­ÖÂÐÅ Today's Network support@now.net.cn »¶Ó­Äú·ÃÎÊÎÒÃǵÄÍøÕ¾ http://www.now.net.cn ÎÒÃÇÒ»Ö±ÒÔרҵ¡¢ÓÅÖÊ¡¢ÁìÏÈΪ×ÚÖ¼£¬ÈȳÏΪÄú·þÎñ£¡ ... ×¢£ºVDNS¿ÉÊÓ»¯ÓòÃû·þÎñÆ÷£¬ÄÜʵÏÖ£Õ£Ò£Ìת·¢¡¢Ö÷»ú£Á¼Ç¼¡¢£Í£ØÓʼþ¼Ç¼¡¢£É£ÐÖ¸Ïò¿ØÖƵȲÙ×÷,¸ü¿ÉÒÔËæÐÄËùÓûµØÔö¼Ó×Ô¼ºµÄ´Î¼¶ÓòÃû£¬°ïÖúÄú½¨Á¢¶à¸öÍøÕ¾£¬Äã¿ÉÒÔÈÃËýÖ¸ÏòÈκοռ䡣 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Aug 7 21:26:47 2001 Delivered-To: freebsd-security@freebsd.org Received: from awww.jeah.net (awww.jeah.net [216.111.239.130]) by hub.freebsd.org (Postfix) with ESMTP id 7D67537B403 for ; Tue, 7 Aug 2001 21:26:36 -0700 (PDT) (envelope-from chris@jeah.net) Received: from localhost (chris@localhost) by awww.jeah.net (8.11.4/8.11.4) with ESMTP id f784PNM03913; Tue, 7 Aug 2001 23:25:24 -0500 (CDT) (envelope-from chris@jeah.net) Date: Tue, 7 Aug 2001 23:25:23 -0500 (CDT) From: Chris Byrnes To: =?X-UNKNOWN?B?zfjC58qxtPo=?= Cc: Subject: =?X-UNKNOWN?B?UmU6IKHu0/LD+9eisuG/1bzkyerH67j3y83I/bj2tM68ttPyw/u7uQ==?= =?X-UNKNOWN?B?w+K30crU08Mh?= In-Reply-To: <20010309133500.28024.qmail@new.now.nxt.cn> Message-ID: <20010807232521.V3910-100000@awww.jeah.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE 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 Score. Chris Byrnes, Managing Member JEAH Communications, LLC On 9 Mar 2001, =CD=F8=C2=E7=CA=B1=B4=FA wrote: > > > =D7=F0=BE=B4=B5=C4=C5=F3=D3=D1=A3=AC=C4=FA=BA=C3=A3=A1 > =B7=C7=B3=A3=B8=D0=D0=BB=C4=FA=B5=C4=E4=AF=C0=C0=A3=AC=C8=E7=B9=FB=C4= =FA=D5=FD=CE=AA=D1=B0=D5=D2=D2=BB=B8=F6=B8=FC=BA=C3=B5=C4ISP=B6=F8=B7=B3=C4= =D5=A3=AC=C4=C7=C3=B4=CE=D2=C3=C7=CD=F8=C2=E7=CA=B1=B4=FAhttp://www.now.net= =2Ecn=CE=AA=C4=FA=CC=E1=B9=A9=C1=CB=D7=EE=BC=D1=B5=C4=D1=A1=D4=F1=A3=A1 > > =A1=EE =D3=F2=C3=FB=D7=A2=B2=E1 > =D7=A2=B2=E1=D3=F2=C3=FB=D4=F9=CB=CD3=B8=F6=B4=CE=BC=B6=D3=F2=C3=FB(=B4= =F8VDNS)=A3=A1 =CD=AC=CA=B1=C9=EA=C7=EB=BF=D5=BC=E4=D4=D9=D4=F9=CB=CD3=B8= =F6=B4=CE=BC=B6=D3=F2=C3=FB=A3=A1 > > =A1=EE=D0=E9=C4=E2=D6=F7=BB=FA > =D2=BB =CC=D8=B6=E0=D3=C5=BB=DD > =B7=B2=D4=DA8.1=B5=BD9.1=D7=A2=B2=E1=D3=F2=C3=FB=CD=AC=CA=B1=C9=EA=C7= =EB=BF=D5=BC=E4=CB=CD6=B8=F6=B4=CE=BC=B6=D3=F2=C3=FB=A3=A1=B5=C8=D3=DA=D2= =BB=B8=F6=D3=F2=C3=FB=BE=CD=C4=DC=CD=AC=CA=B1=BD=A86=B8=F6=CD=F8=D5=BE=A3= =A1=CD=AC=CA=B1=BC=D3=CB=CD15=B8=F6=C9=CC=D3=C3=D3=CA=BC=FE=D5=CB=BA=C5=A3= =A1 > > =B6=FE =B3=AC=B5=CD=CC=D8=BC=DB > 280=D4=AA=A3=A1=C4=FA=BF=C9=D2=D4=C1=A2=BF=CC=D3=B5=D3=D0=CE=C8=B6=A8= =B6=F8=BF=EC=CB=D9=B5=C4100M=D0=E9=C4=E2=D6=F7=BB=FA=BF=D5=BC=E4!=BB=B9=D3= =CC=D4=A5=CA=B2=C3=B4=C4=D8=A3=AC=B8=CF=BF=EC=D0=D0=B6=AF=B0=C9=A3=A1 > > =C8=FD =B3=B9=B5=D7=BD=E2=B7=C5 > =CF=D6=D4=DA=CC=EC=BB=A5=BF=C6=BC=BC=B5=C4ASP=BA=CDACCESS=CA=FD=BE=DD= =BF=E2=C8=AB=C3=E6=BF=AA=B7=C5=A3=AC=D6=BB=D0=E8100=D4=AA=BE=CD=C8=C3=C4=FA= =B5=C4=CD=F8=D5=BE=D3=B5=D3=D0=CA=FD=BE=DD=BF=E2=A1=A3 > =B2=A2=D3=D0=CC=E1=B9=A9CGI PERL PHP JSP =B5=C8=D2=BB=CC=E5=B8=DF=BC=B6= =BF=D5=BC=E4.=CB=F9=D3=D0=BF=D5=BC=E4=CA=B5=CA=B1=BF=AA=CD=A8=C3=E2=B7=D1= =CA=D4=D3=C315=CC=EC! > > > =A1=EE=A1=EE"=BB=F0=BA=EC=CF=C4=C8=D5=A1=B1=D6=F7=BB=FA=CD=D0=B9=DC=D3= =C5=BB=DD=EC=AB=B7=E7=C8=AB=C3=E6=B5=C7=C2=BD=A3=AC=C7=BF=B4=F3=A1=A2=B8=DF= =B1=EA=D7=BC=B5=C4=B5=E7=D0=C5=BC=B6=CA=FD=BE=DD=D6=D0=D0=C4=BB=FA=B7=BF=A3= =AC=B8=DF=B0=B2=C8=AB=CC=D8=D0=D4=A1=A2=B8=DF=B7=FE=CE=F1=B1=EA=D7=BC=A1=A2= =D4=D9=BC=D3=C9=CF=BA=CF=C0=ED=B5=C4=BC=DB=B8=F1=A3=AC=CF=F2=B9=E3=B4=F3= =BF=CD=BB=A7=CC=E1=B9=A9=B8=DF=D0=D4=BC=DB=B1=C8=B5=C4=B7=FE=CE=F1=A1=A3=CF= =EA=BC=FBhttp://idc.now.net.cn > =A1=EE=A1=EE=CD=AC=CA=B1=CE=D2=C3=C7=CF=F2=B9=E3=B4=F3=B8=F7=BD=EC=B3=CF= =D5=F7=B4=FA=C0=ED=A3=AC=C8=C8=B3=C0=D1=FB=C7=EB=C4=FA=BC=D3=C8=EB=CD=F8=C2= =E7=CA=B1=B4=FA=B5=C4=D2=B5=CE=F1=BA=CF=D7=F7=D5=F3=D3=AA=A3=AC=B9=B2=CD=AC= =B7=D6=CF=ED=CD=F8=C2=E7=CA=B1=B4=FA=B5=C4=C5=D3=B4=F3=BF=CD=BB=A7=D7=CA=D4= =B4=A1=A3=CF=EA=CF=B8=C7=EB=B7=C3=CE=CA=CE=D2=C3=C7=CD=F8=D5=BE=A1=A3 > =BB=F2=D6=B1=BD=D3=C1=AA=CF=B5=CE=D2=C3=C7: > =C7=F1=D0=A1=BD=E3 michelle@now.net.cn > =C1=D6=CF=C8=C9=FA youko@now.net.cn=A1=A1=A1=A1=A1=A1 > =B5=E7=BB=B0=A3=BA0756-2125583 22216376 > =BC=BC=CA=F5=B2=BF=A3=BA > sanry@now.net.cn youko@now.net.cn > 0756--2216376 2139739 > > =BB=B6=D3=AD=D6=C2=D0=C5 Today's Network support@now.net.cn > =BB=B6=D3=AD=C4=FA=B7=C3=CE=CA=CE=D2=C3=C7=B5=C4=CD=F8=D5=BE http://www.n= ow.net.cn > > =CE=D2=C3=C7=D2=BB=D6=B1=D2=D4=D7=A8=D2=B5=A1=A2=D3=C5=D6=CA=A1=A2=C1=EC= =CF=C8=CE=AA=D7=DA=D6=BC=A3=AC=C8=C8=B3=CF=CE=AA=C4=FA=B7=FE=CE=F1=A3=A1 > > ... > =D7=A2=A3=BAVDNS=BF=C9=CA=D3=BB=AF=D3=F2=C3=FB=B7=FE=CE=F1=C6=F7=A3=AC=C4= =DC=CA=B5=CF=D6=A3=D5=A3=D2=A3=CC=D7=AA=B7=A2=A1=A2=D6=F7=BB=FA=A3=C1=BC=C7= =C2=BC=A1=A2=A3=CD=A3=D8=D3=CA=BC=FE=BC=C7=C2=BC=A1=A2=A3=C9=A3=D0=D6=B8=CF= =F2=BF=D8=D6=C6=B5=C8=B2=D9=D7=F7,=B8=FC=BF=C9=D2=D4=CB=E6=D0=C4=CB=F9=D3= =FB=B5=D8=D4=F6=BC=D3=D7=D4=BC=BA=B5=C4=B4=CE=BC=B6=D3=F2=C3=FB=A3=AC=B0=EF= =D6=FA=C4=FA=BD=A8=C1=A2=B6=E0=B8=F6=CD=F8=D5=BE=A3=AC=C4=E3=BF=C9=D2=D4=C8= =C3=CB=FD=D6=B8=CF=F2=C8=CE=BA=CE=BF=D5=BC=E4=A1=A3 > > > > 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 Aug 8 4:30: 8 2001 Delivered-To: freebsd-security@freebsd.org Received: from pericles.IPAustralia.gov.au (pericles.IPAustralia.gov.au [202.14.186.30]) by hub.freebsd.org (Postfix) with ESMTP id DB9C437B413; Wed, 8 Aug 2001 04:29:58 -0700 (PDT) (envelope-from anwsmh@IPAustralia.Gov.AU) Received: (from smap@localhost) by pericles.IPAustralia.gov.au (8.11.3/8.11.1) id f78BTqQ60215; Wed, 8 Aug 2001 21:29:52 +1000 (EST) (envelope-from anwsmh@IPAustralia.Gov.AU) Received: from wf-138.aipo.gov.au(192.168.1.138) by pericles.IPAustralia.gov.au via smap (V2.1) id xma060213; Wed, 8 Aug 01 21:29:50 +1000 Received: (from anwsmh@localhost) by stan.aipo.gov.au (8.11.1/8.11.1) id f78BTp900605; Wed, 8 Aug 2001 21:29:51 +1000 (EST) (envelope-from anwsmh@IPAustralia.Gov.AU) X-Authentication-Warning: stan.aipo.gov.au: anwsmh set sender to anwsmh@IPAustralia.Gov.AU using -f Date: Wed, 8 Aug 2001 21:29:50 +1000 From: Stanley Hopcroft To: ISP@FreeBSD.ORG Cc: Security@FreeBSD.ORG Subject: Having a FreeBSD based firewall approved for Australian Government use (getting on EPL) Message-ID: <20010808212948.A575@IPAustralia.Gov.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 Dear Ladies and Gentlemen, I am writing to invite expressions of interest from those who may wish to help pay the fee to have FreeBSD and other open source software evaluated and approved as firewall products for Australian Government use (products that meet the 'common criteria' at the E3 level and have been independently validated - that's the fee part - and so become part of the 'Endorsed Product List [EPL]). The background is that my employer has been a happy user of a FreeBSD based firewall for some years but with a change to a more risk averse and ignorant management, the cost of the firewall is being compared to outsourcing the service, or replacing it by a Commonwealth of Australia approved firewall (an E3 rated product from the EPL). Such products include PIX (?? maybe E1 only) and Gauntlet. Maybe Firewall-1. Part of the attraction of having FreeBSD on the EPL is commercial products drop of the EPL at the whim of the vendor, and one is faced with the prospect of doing it all gain with a different product. A very sensible man has suggested that the cost of hardware, approved software and setup may in fact approach the A $100k for the evaluation fee (the evaluation is __not__ like the Orange book approach. An E3 rating means something like an inspection of the source has shown evidence of software engineering principles). Obviously we will only proceed if we find we can save money by using software that we like and have found trustworthy. We would submit FreeBSD RELEASE and some other famous name software for evaluation (and reevaluation when the software changes). The TrustedBSD project is obviously an alternative and probably superior approach but we cannot afford to wait for its release. Should anyone be interested in a consortium approach to having FreeBSD being approved for the Australian EPL, or wish to share any advice about this matter, please let me know. Thank you, Yours sincerely. -- ------------------------------------------------------------------------ Stanley Hopcroft IP Australia Network Specialist +61 2 6283 3189 +61 2 6281 1353 (FAX) Stanley.Hopcroft@IPAustralia.Gov.AU ------------------------------------------------------------------------ Reclaimer, spare that tree! Take not a single bit! It used to point to me, Now I'm protecting it. It was the reader's CONS That made it, paired by dot; Now, GC, for the nonce, Thou shalt reclaim it not. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 5:42:44 2001 Delivered-To: freebsd-security@freebsd.org Received: from ---- (c242.h061016011.is.net.tw [61.16.11.242]) by hub.freebsd.org (Postfix) with SMTP id E8A6C37B41B; Wed, 8 Aug 2001 05:34:27 -0700 (PDT) (envelope-from linux18@ms68.url.com.tw) Received: from ara by tcts.seed.net.tw with SMTP id guPxsftzmFvn9XUipRZIC; Wed, 08 Aug 2001 20:35:15 +0800 Message-ID: From: ¤E¤Q¦~«×¤½¶O¸É§U@FreeBSD.ORG To: µL@FreeBSD.ORG Subject:=?big5?Q?=A6=E6=ACF=B0|=A4=BD=B6O=B0=F6=B0V?= MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_yZNwfFJIk6XxQT65OJs" X-Mailer: YGY09oefdD4SLOr X-Priority: 3 X-MSMail-Priority: Normal Date: Wed, 8 Aug 2001 05:34:27 -0700 (PDT) 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 This is a multi-part message in MIME format. ------=_NextPart_yZNwfFJIk6XxQT65OJs Content-Type: multipart/alternative; boundary="----=_NextPart_yZNwfFJIk6XxQT65OJsAA" ------=_NextPart_yZNwfFJIk6XxQT65OJsAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PCEtLSBzYXZlZCBmcm9tIHVybD0oMDAyMilodHRwOi8vaW50ZXJuZXQuZS1tYWlsIC0tPg0KPCEt LSBzYXZlZCBmcm9tIHVybD0oMDAyMilodHRwOi8vaW50ZXJuZXQuZS1tYWlsIC0tPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtTGFuZ3VhZ2UiIGNvbnRlbnQ9ImVu LXVzIj4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PWJpZzUiPg0KPG1ldGEgbmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJNaWNyb3Nv ZnQgRnJvbnRQYWdlIDQuMCI+DQo8bWV0YSBuYW1lPSJQcm9nSWQiIGNvbnRlbnQ9IkZyb250UGFn ZS5FZGl0b3IuRG9jdW1lbnQiPg0KPHRpdGxlPrdzuvSttjE8L3RpdGxlPg0KPC9oZWFkPg0KPGJv ZHkgYmFja2dyb3VuZD0iaHR0cDovL3d3dy5sY2NuZXQuY29tLnR3L2xpbnV4L2xpbnV4c2hvdy9p bWFnZXMvMi9iYWNrZ3JvdW5kLkpQRyI+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPg0KPHRhYmxlIGJv cmRlcj0iMSIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iNzAwIiBiZ2Nv bG9yPSIjMDA2NjAwIiBib3JkZXJjb2xvcmxpZ2h0PSIjODA4MDgwIiBib3JkZXJjb2xvcmRhcms9 IiNGRkZGRkYiPg0KPHRyPjx0ZD4NCjxkaXYgYWxpZ249ImNlbnRlciI+DQogIDxjZW50ZXI+DQog IDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9 IjEwMCUiPg0KICAgIDx0cj4NCiAgICAgIDx0ZCB3aWR0aD0iNTAlIj4NCiAgICAgICAgPHAgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAxNTAlOyB3b3JkLXNwYWNpbmc6IDA7IG1hcmdpbi1sZWZ0OiA1OyBt YXJnaW4tcmlnaHQ6IDU7IG1hcmdpbi10b3A6IDA7IG1hcmdpbi1ib3R0b206IDAiPjwvdGQ+DQog ICAgPC9jZW50ZXI+DQogICAgPHRkIHdpZHRoPSI1MCUiPg0KICAgICAgPHAgc3R5bGU9ImxpbmUt aGVpZ2h0OiAxNTAlOyB3b3JkLXNwYWNpbmc6IDA7IG1hcmdpbjogNSIgYWxpZ249InJpZ2h0Ij48 c3BhbiBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6IDJwdCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMw MEZGMDAiPrLEpEexTar4oUKyxKRAv+++3CANCiAgICAgIKaorLAgPC9mb250Pjxmb250IGNvbG9y PSIjMDBGRjAwIiBzaXplPSIzIj48aT4yMaVArPa46rBUpEg8L2k+PC9mb250Pjwvc3Bhbj48L3Rk Pg0KICA8L3RyPg0KICA8L3RhYmxlPg0KPC9kaXY+DQo8Y2VudGVyPg0KPHRhYmxlIGJvcmRlcj0i MCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iMTAwJSIgYmdjb2xvcj0i I0ZGRkZGRiIgYmFja2dyb3VuZD0iaHR0cDovL3d3dy5sY2NuZXQuY29tLnR3L2xpbnV4L2xpbnV4 c2hvdy9pbWFnZXMvMi9iYWNrZ3JvdW5kLkpQRyI+DQo8dHI+PHRkIHdpZHRoPSIxMDAlIj4NCjxw IHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxNTAlOyBtYXJnaW4tbGVmdDog MDsgbWFyZ2luLXJpZ2h0OiAwOyBtYXJnaW4tdG9wOiAyMDsgbWFyZ2luLWJvdHRvbTogNSIgYWxp Z249ImNlbnRlciI+PGZvbnQgZmFjZT0ivNC3osXpIiBzaXplPSI2IiBjb2xvcj0iIzAwMDA4MCI+ puasRrB8rOyn3qRIpH6w9rBWpM65QqXOpOiu1zwvZm9udD48L3A+DQogIDwvY2VudGVyPiAgICAg ICAgICAgICAgICANCjxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxNTAl OyBtYXJnaW4tbGVmdDogMDsgbWFyZ2luLXJpZ2h0OiAwOyBtYXJnaW4tdG9wOiAxNTsgbWFyZ2lu LWJvdHRvbTogNSIgYWxpZ249ImNlbnRlciI+PGZvbnQgY29sb3I9IiNGRjAwMDAiIGZhY2U9IrzQ t6LF6SIgc2l6ZT0iNSI+pL22T7jJp1W46rBUs27F6aRIpH6w9rBWs3GqvjwvZm9udD48L3A+DQo8 Y2VudGVyPg0KPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDEwMCU7IG1h cmdpbjogMCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD48L3A+DQog IDwvY2VudGVyPiAgICAgICAgICAgICAgICANCiAgPGRpdiBhbGlnbj0ibGVmdCI+DQogICAgPHRh YmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iOTUi Pg0KICAgICAgPHRyPg0KICAgICAgICA8dGQgd2lkdGg9IjkzIiBiZ2NvbG9yPSIjMDA2NjY2Ij4g ICAgICAgICAgICAgICAgDQo8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDog MTUwJTsgbWFyZ2luOiAwIj48Zm9udCBjb2xvcj0iI0ZGRkZGRiI+Jm5ic3A7ICANCjwvZm9udD48 Zm9udCBzaXplPSIyIiBjb2xvcj0iI0ZGRkZGRiI+s/yhQq1wtWWk6LB3PC9mb250Pjxmb250IGNv bG9yPSIjRkZGRkZGIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250PjwvcD4NCiAg ICAgICAgPC90ZD4NCiAgICAgIDwvdHI+DQogICAgPC90YWJsZT4NCiAgPC9kaXY+DQo8Y2VudGVy Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj4NCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iOTUlIj4NCiAgICA8dHI+DQogICAgICA8dGQgd2lk dGg9IjEwMCUiPg0KICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdo dDogMTAwJTsgbWFyZ2luLWxlZnQ6IDA7IG1hcmdpbi1yaWdodDogMDsgbWFyZ2luLXRvcDogMzsg bWFyZ2luLWJvdHRvbTogMCI+PGZvbnQgc2l6ZT0iMiI+sPawVqtEuOqwVKzbw/as7Kh0sqa3fqSn pEit+6FBqPOnVbKjt361b65poUGow7jRqE2lord+sN3DRKFDPC9mb250PjwvcD4NCiAgICAgICAg PHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDEwMCU7IG1hcmdpbjogMCI+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD48L3RkPg0KICAgIDwvdHI+ DQogIDwvdGFibGU+DQo8L2Rpdj4NCiAgPC9jZW50ZXI+ICAgICAgICAgICAgICAgIA0KICA8ZGl2 IGFsaWduPSJsZWZ0Ij4NCiAgICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2Vs bHNwYWNpbmc9IjAiIHdpZHRoPSI5NCI+DQogICAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0aD0i OTIiIGJnY29sb3I9IiMwMDY2NjYiPg0KICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6 IDA7IGxpbmUtaGVpZ2h0OiAxNTAlOyBtYXJnaW46IDAiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiAjMDA2NjY2Ij48Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiIgZmFjZT0iQXJp YWwiPiZuYnNwOyANCiAgICAgICAgICA8L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiNGRkZG RkYiPrZMoUKtcLm6qMw8L2ZvbnQ+PC9zcGFuPjxmb250IHNpemU9IjIiIGNvbG9yPSIjRkZGRkZG Ij6+2jwvZm9udD48L3RkPg0KICAgICAgPC90cj4NCiAgICA8L3RhYmxlPg0KICA8L2Rpdj4NCjxj ZW50ZXI+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPg0KICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI5NSUiPg0KICAgIDx0cj4NCiAgICAgIDx0 ZCB3aWR0aD0iMTAwJSI+DQogICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUt aGVpZ2h0OiAxMDAlOyBtYXJnaW4tbGVmdDogMDsgbWFyZ2luLXJpZ2h0OiAwOyBtYXJnaW4tdG9w OiAzOyBtYXJnaW4tYm90dG9tOiAwIj48Zm9udCBzaXplPSIyIj6ozKF1puasRrB8rOyn3qRIpH6w 9rBWpM65QqXOpOiu16F2v+yyeqFBuXem9LD2sFa4Z7ZPrLC3c6V4ufS4drv1pLihQbl3rXCw9rBW pEC4VaRIprikp7jqsFSzbsXppEikfqfrpEq0Trd+pauz9aFDPC9mb250PjwvcD4NCiAgICAgICAg PHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDEwMCU7IG1hcmdpbjogMCI+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCiAgICAgIDwvdGQ+DQog ICAgPC90cj4NCiAgPC90YWJsZT4NCjwvZGl2Pg0KICA8L2NlbnRlcj4gICAgICAgICAgICAgICAg DQogIDxkaXYgYWxpZ249ImxlZnQiPg0KICAgIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9IjkzIj4NCiAgICAgIDx0cj4NCiAgICAgICAgPHRk IHdpZHRoPSI5MSIgYmdjb2xvcj0iIzAwNjY2NiI+DQogICAgICAgICAgPHAgc3R5bGU9IndvcmQt c3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDE1MCU7IG1hcmdpbjogMCI+PHNwYW4gc3R5bGU9ImJh Y2tncm91bmQtY29sb3I6ICMwMDY2NjYiPjxmb250IGNvbG9yPSIjRkZGRkZGIj4mbmJzcDsgDQog ICAgICAgICAgPC9mb250Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjRkZGRkZGIj6w0aFCpUS/7LPm PC9mb250Pjwvc3Bhbj48Zm9udCBzaXplPSIyIiBjb2xvcj0iI0ZGRkZGRiI+puw8L2ZvbnQ+PC90 ZD4NCiAgICAgIDwvdHI+DQogICAgPC90YWJsZT4NCiAgPC9kaXY+DQo8Y2VudGVyPg0KPGRpdiBh bGlnbj0iY2VudGVyIj4NCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIwIiB3aWR0aD0iOTUlIj4NCiAgICA8dHI+DQogICAgICA8dGQgd2lkdGg9IjEwMCUi Pg0KICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTAwJTsg bWFyZ2luLWxlZnQ6IDA7IG1hcmdpbi1yaWdodDogMDsgbWFyZ2luLXRvcDogMTA7IG1hcmdpbi1i b3R0b206IDAiPjxmb250IGNvbG9yPSIjMDAwMEZGIj48Yj6m5qxGsHyz0qllt3zCvrBWp72hQqbm rEawfKtDu7K3fDwvYj48L2ZvbnQ+PC9wPg0KICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5n OiAwOyBsaW5lLWhlaWdodDogMTAwJTsgbWFyZ2luOiAwIj48Zm9udCBzaXplPSIyIiBmYWNlPSJB cmlhbCI+Jm5ic3A7PC9mb250PjwvdGQ+DQogICAgPC90cj4NCiAgPC90YWJsZT4NCjwvZGl2Pg0K ICA8L2NlbnRlcj4gICAgICAgICAgICAgICAgDQogIDxkaXYgYWxpZ249ImxlZnQiPg0KICAgIDx0 YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9Ijkz Ij4NCiAgICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI5MSIgYmdjb2xvcj0iIzAwNjY2NiI+ DQogICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDE1MCU7 IG1hcmdpbjogMCI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICMwMDY2NjYiPjxmb250 IGNvbG9yPSIjRkZGRkZGIj4mbmJzcDsgDQogICAgICAgICAgPC9mb250Pjxmb250IHNpemU9IjIi IGNvbG9yPSIjRkZGRkZGIj64dqFCqWW/7LPmPC9mb250Pjwvc3Bhbj48Zm9udCBzaXplPSIyIiBj b2xvcj0iI0ZGRkZGRiI+puw8L2ZvbnQ+PC90ZD4gDQogICAgICA8L3RyPiANCiAgICA8L3RhYmxl PiANCiAgPC9kaXY+IA0KPGNlbnRlcj4gIA0KPGRpdiBhbGlnbj0iY2VudGVyIj4gICAgICAgICAg ICAgICAgICAgIA0KICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjAiIHdpZHRoPSI5NSUiPiAgICAgICAgICAgICAgICAgICAgDQogICAgPHRyPiAgICAgICAg ICAgICAgICAgICAgDQogICAgICA8dGQgd2lkdGg9IjEwMCUiPiAgICAgICAgICAgICAgICAgICAg DQogICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBt YXJnaW4tbGVmdDogMDsgbWFyZ2luLXJpZ2h0OiAwOyBtYXJnaW4tdG9wOiAzOyBtYXJnaW4tYm90 dG9tOiAwIj48Zm9udCBjb2xvcj0iIzAwMDBGRiIgc2l6ZT0iMiI+wXCmqLlxuKOx0Kh8pKSk3zwv Zm9udD48L3A+ICAgICAgICAgICAgICANCiAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzog MDsgbGluZS1oZWlnaHQ6IDEwMCU7IG1hcmdpbjogMCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJp YWwiPiZuYnNwOzwvZm9udD48L3RkPiAgICAgICAgICAgICAgICAgICANCiAgICA8L3RyPiAgICAg ICAgICAgICAgICAgICANCiAgPC90YWJsZT4gICAgICAgICAgICAgICAgICAgDQo8L2Rpdj4gICAg ICAgICAgICAgICAgICAgDQogIDwvY2VudGVyPiAgICAgICAgICAgICAgICAgIA0KICA8ZGl2IGFs aWduPSJsZWZ0Ij4NCiAgICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjAiIHdpZHRoPSI5MyI+DQogICAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0aD0iOTEi IGJnY29sb3I9IiMwMDY2NjYiPg0KICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7 IGxpbmUtaGVpZ2h0OiAxNTAlOyBtYXJnaW46IDAiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNv bG9yOiAjMDA2NjY2Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+Jm5ic3A7ICAgICAgICAg ICAgICANCiAgICAgICAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiPqXu oUKw9rBWPC9zcGFuPsP+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICMwMDY2NjYiPqdP PC9zcGFuPjwvZm9udD48L3RkPg0KICAgICAgPC90cj4NCiAgICA8L3RhYmxlPg0KICA8L2Rpdj4N CjxjZW50ZXI+IA0KPGRpdiBhbGlnbj0iY2VudGVyIj4gICAgICAgICAgICAgDQogIDx0YWJsZSBi b3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9Ijk1JSI+ICAg ICAgICAgICAgIA0KICAgIDx0cj4gICAgICAgICAgICAgDQogICAgICA8dGQgd2lkdGg9IjEwMCUi PiAgICAgICAgICAgICANCiAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1o ZWlnaHQ6IDEwMCU7IG1hcmdpbi1sZWZ0OiAwOyBtYXJnaW4tcmlnaHQ6IDA7IG1hcmdpbi10b3A6 IDM7IG1hcmdpbi1ib3R0b206IDAiPjxmb250IHNpemU9IjIiPrr0u9q69Lj0uOquxq53s12tcK9a oUK46q7GrnfAs6XOtXumobNdrXCvWqFCtXumobNdrXCvWqFDPC9mb250PjwvcD4gICAgICAgICAg ICAgDQogICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAl OyBtYXJnaW46IDAiPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+PC90 ZD4gICAgICAgICAgICAgDQogICAgPC90cj4gICAgICAgICAgICAgDQogIDwvdGFibGU+ICAgICAg ICAgICAgIA0KPC9kaXY+ICAgICAgICAgICAgIA0KICA8L2NlbnRlcj4gICAgICAgICAgICAgICAg IA0KICA8ZGl2IGFsaWduPSJsZWZ0Ij4NCiAgICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI5NCI+DQogICAgICA8dHI+DQogICAgICAgIDx0 ZCB3aWR0aD0iOTIiIGJnY29sb3I9IiMwMDY2NjYiPg0KICAgICAgICAgIDxwIHN0eWxlPSJ3b3Jk LXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxNTAlOyBtYXJnaW46IDAiPjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kLWNvbG9yOiAjMDA2NjY2Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+Jm5i c3A7ICAgICAgICAgICAgICANCiAgICAgICAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYi IHNpemU9IjIiPrOwoUK+x7ZPPC9zcGFuPrjJPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6 ICMwMDY2NjYiPqdVPC9zcGFuPjwvZm9udD48L3RkPg0KICAgICAgPC90cj4NCiAgICA8L3RhYmxl Pg0KICA8L2Rpdj4NCjxjZW50ZXI+IA0KPGRpdiBhbGlnbj0iY2VudGVyIj4gICAgICAgICAgICAg ICAgICANCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIw IiB3aWR0aD0iOTUlIj4gICAgICAgICAgICAgICAgICANCiAgICA8dHI+ICAgICAgICAgICAgICAg ICAgDQogICAgICA8dGQgd2lkdGg9IjEwMCUiPiAgICAgICAgICAgICAgICAgIA0KICAgICAgICA8 cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTAwJTsgbWFyZ2luLWxlZnQ6 IDA7IG1hcmdpbi1yaWdodDogMDsgbWFyZ2luLXRvcDogMzsgbWFyZ2luLWJvdHRvbTogMCI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiNGRjAwMDAiPqF5puasRrB8s9Kkdallrfu3fLROt36md6l3sPKq 96F6PC9mb250PjxiPjxmb250IGNvbG9yPSIjRkYwMDAwIj64yadVvse2TzIvMzwvZm9udD48L2I+ PGZvbnQgc2l6ZT0iMiI+PGZvbnQgY29sb3I9IiNGRjAwMDAiPqFBPC9mb250Pr7Hrfum26VJMSAv IDOhQzwvZm9udD48L3A+ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICA8cCBzdHlsZT0id29y ZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTAwJTsgbWFyZ2luOiAwIj48Zm9udCBzaXplPSIy IiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250PjwvdGQ+ICAgICAgICAgICAgICAgICAgICAgICAg DQogICAgPC90cj4gICAgICAgICAgICAgICAgICAgICAgICANCiAgPC90YWJsZT4gICAgICAgICAg ICAgICAgICAgICAgICANCjwvZGl2PiAgICAgICAgICAgICAgICAgICAgICAgIA0KICA8L2NlbnRl cj4gICAgICAgICAgICAgICAgICAgICAgDQogIDxkaXYgYWxpZ249ImxlZnQiPiAgICANCiAgICA8 dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSIx MTYiPiAgICANCiAgICAgIDx0cj4gICAgDQogICAgICAgIDx0ZCB3aWR0aD0iMTE0IiBiZ2NvbG9y PSIjMDA2NjY2Ij4gICAgDQogICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGlu ZS1oZWlnaHQ6IDE1MCU7IG1hcmdpbjogMCI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6 ICMwMDY2NjYiPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj4mbmJzcDsgICAgICAgICAgICAg ICAgICANCiAgICAgICAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiPqxt oUKwVr1tpc08L3NwYW4+rKE8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogIzAwNjY2NiI+ rHq2Szwvc3Bhbj48L2ZvbnQ+PC90ZD4gIA0KICAgICAgPC90cj4gIA0KICAgIDwvdGFibGU+ICAN CiAgPC9kaXY+ICANCjxjZW50ZXI+ICAgDQo8ZGl2IGFsaWduPSJjZW50ZXIiPiAgICAgICAgICAg ICAgICAgICAgICANCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIwIiB3aWR0aD0iOTUlIj4gICAgICAgICAgICAgICAgICAgICAgDQogICAgPHRyPiAgICAg ICAgICAgICAgICAgICAgICANCiAgICAgIDx0ZCB3aWR0aD0iMTAwJSI+ICAgICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDog MTAwJTsgbWFyZ2luLWxlZnQ6IDA7IG1hcmdpbi1yaWdodDogMDsgbWFyZ2luLXRvcDogMzsgbWFy Z2luLWJvdHRvbTogMCI+PGZvbnQgc2l6ZT0iMiI+ssWmWKxGqbKhdTxmb250IGNvbG9yPSIjRkYw MDAwIj6wVr1tpc2soax6tks8L2ZvbnQ+oXa46q7mqsyhQTxmb250IGNvbG9yPSIjRkYwMDAwIj6o Q6TrpWmk5Lvit3OleLn0s/y4VbZMpGSkuDwvZm9udD6hQzwvZm9udD48L3A+ICAgICAgICAgICAg ICANCiAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDEwMCU7 IG1hcmdpbjogMCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD48L3Rk PiAgICAgICAgICAgICAgICAgICANCiAgICA8L3RyPiAgICAgICAgICAgICAgICAgICANCiAgPC90 YWJsZT4gICAgICAgICAgICAgICAgICAgDQo8L2Rpdj4gICAgICAgICAgICAgICAgICAgDQogIDwv Y2VudGVyPiAgICAgICAgICAgICAgICAgIA0KICA8ZGl2IGFsaWduPSJsZWZ0Ij4gDQogICAgPHRh YmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iOTMi PiANCiAgICAgIDx0cj4gDQogICAgICAgIDx0ZCB3aWR0aD0iOTEiIGJnY29sb3I9IiMwMDY2NjYi PiANCiAgICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTUw JTsgbWFyZ2luOiAwIj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogIzAwNjY2NiI+PGZv bnQgZmFjZT0iQXJpYWwiPiZuYnNwOyAgICAgICAgICAgICAgDQogICAgICAgICAgPC9mb250Pjxm b250IHNpemU9IjIiIGNvbG9yPSIjRkZGRkZGIj6uw6FCrta1b8PSPC9mb250Pjwvc3Bhbj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iI0ZGRkZGRiI+t9M8L2ZvbnQ+PHNwYW4gc3R5bGU9ImJhY2tncm91 bmQtY29sb3I6ICMwMDY2NjYiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBjb2xvcj0iI0ZG RkZGRiI+Jm5ic3A7PC9mb250Pjwvc3Bhbj48L3RkPiANCiAgICAgIDwvdHI+IA0KICAgIDwvdGFi bGU+IA0KICA8L2Rpdj4gDQo8Y2VudGVyPiAgDQo8ZGl2IGFsaWduPSJjZW50ZXIiPiAgICAgICAg ICAgICAgIA0KICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjAiIHdpZHRoPSI5NSUiPiAgICAgICAgICAgICAgIA0KICAgIDx0cj4gICAgICAgICAgICAgICAN CiAgICAgIDx0ZCB3aWR0aD0iMTAwJSI+ICAgICAgICAgICAgICAgDQogICAgICAgIDxwIHN0eWxl PSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW4tbGVmdDogMDsgbWFy Z2luLXJpZ2h0OiAwOyBtYXJnaW4tdG9wOiAzOyBtYXJnaW4tYm90dG9tOiAwIj48Zm9udCBzaXpl PSIyIj61srd+pqjBWqZYruaqzKFBtW+1uTxmb250IGNvbG9yPSIjRkYwMDAwIj6mWK7mpKfD0q7R PC9mb250PqFDPC9mb250PiAgICAgICAgICAgICAgDQogICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNw YWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW46IDAiPjxmb250IHNpemU9IjIiIGZh Y2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+PC90ZD4gICAgICAgICAgICAgIA0KICAgIDwvdHI+ICAg ICAgICAgICAgICANCiAgPC90YWJsZT4gICAgICAgICAgICAgIA0KPC9kaXY+ICAgICAgICAgICAg ICANCiAgPC9jZW50ZXI+ICAgICAgICAgICAgICAgICAgDQogIDxkaXYgYWxpZ249ImxlZnQiPiAN CiAgICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdp ZHRoPSI5MyI+IA0KICAgICAgPHRyPiANCiAgICAgICAgPHRkIHdpZHRoPSI5MSIgYmdjb2xvcj0i IzAwNjY2NiI+IA0KICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVp Z2h0OiAxNTAlOyBtYXJnaW46IDAiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjMDA2 NjY2Ij48Zm9udCBmYWNlPSJBcmlhbCI+Jm5ic3A7ICAgICAgICAgICAgIA0KICAgICAgICAgIDwv Zm9udD48L3NwYW4+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiNGRkZGRkYiPjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kLWNvbG9yOiAjMDA2NjY2Ij6oaKFCtE63fr73PC9zcGFuPrd8PC9mb250PjxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjMDA2NjY2Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6 ZT0iMiIgY29sb3I9IiNGRkZGRkYiPiZuYnNwOzwvZm9udD48L3NwYW4+PC90ZD4gDQogICAgICA8 L3RyPiANCiAgICA8L3RhYmxlPiANCiAgPC9kaXY+IA0KPGNlbnRlcj4gDQo8ZGl2IGFsaWduPSJj ZW50ZXIiPiAgICAgICAgICAgICANCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iOTUlIj4gICAgICAgICAgICAgDQogICAgPHRyPiAgICAg ICAgICAgICANCiAgICAgIDx0ZCB3aWR0aD0iMTAwJSI+ICAgICAgICAgICAgIA0KICAgICAgICA8 cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTAwJTsgbWFyZ2luLWxlZnQ6 IDA7IG1hcmdpbi1yaWdodDogMDsgbWFyZ2luLXRvcDogMzsgbWFyZ2luLWJvdHRvbTogMCI+PGZv bnQgc2l6ZT0iMiI+tKOo0TwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+MjIsODU0 PC9mb250Pjxmb250IHNpemU9IjIiPq3TtE63fr73t3yhQbx4pH68dLDTprPBcLlxoUK12LrToUKt XrS2uUahQqV4xlepVLr0oUKvq7lGoUK0ZrS2rOyn3qFCpXi/brlxoUKnu/nWuXG4ozwvZm9udD48 Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+Li4uPC9mb250Pjxmb250IHNpemU9IjIiPrWlplWk aqS9pXE8L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPig8L2ZvbnQ+PGZvbnQgc2l6 ZT0iMiI+u1CkSKRPuOq3vbr0plinQDwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+ KTwvZm9udD48Zm9udCBzaXplPSIyIj6hQzwvZm9udD48L3A+ICAgICAgICAgICAgICANCiAgICAg ICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDEwMCU7IG1hcmdpbjog MCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD48L3RkPiAgICAgICAg ICAgICAgDQogICAgPC90cj4gICAgICAgICAgICAgIA0KICA8L3RhYmxlPiAgICAgICAgICAgICAg DQo8L2Rpdj4gICAgICAgICAgICAgIA0KICA8L2NlbnRlcj4gICAgICAgICAgICAgICAgIA0KICA8 ZGl2IGFsaWduPSJsZWZ0Ij4gDQogICAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iOTQiPiANCiAgICAgIDx0cj4gDQogICAgICAgIDx0ZCB3 aWR0aD0iOTIiIGJnY29sb3I9IiMwMDY2NjYiPiANCiAgICAgICAgICA8cCBzdHlsZT0id29yZC1z cGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTUwJTsgbWFyZ2luOiAwIj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjogIzAwNjY2NiI+PGZvbnQgZmFjZT0iQXJpYWwiPiZuYnNwOyAgICAgICAg ICAgICANCiAgICAgICAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiPqxC oUKz+KZXtME8L2ZvbnQ+PC9zcGFuPjxmb250IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIyIj6trTwv Zm9udD48L3RkPiANCiAgICAgIDwvdHI+IA0KICAgIDwvdGFibGU+IA0KICA8L2Rpdj4gDQo8Y2Vu dGVyPiANCjxkaXYgYWxpZ249ImNlbnRlciI+ICAgICAgICAgICAgDQogIDx0YWJsZSBib3JkZXI9 IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9Ijk1JSI+ICAgICAgICAg ICAgDQogICAgPHRyPiAgICAgICAgICAgIA0KICAgICAgPHRkIHdpZHRoPSIxMDAlIj4gICAgICAg ICAgICANCiAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDEw MCU7IG1hcmdpbi1sZWZ0OiAwOyBtYXJnaW4tcmlnaHQ6IDA7IG1hcmdpbi10b3A6IDM7IG1hcmdp bi1ib3R0b206IDAiPjxmb250IGNvbG9yPSIjRkYwMDAwIiBzaXplPSIyIj6nWaTpsF+m3CCkRSCk USCmfiCkSyCk6yCkUSAgICAgDQogICAgICAgIKV8IKTppO48L2ZvbnQ+PGZvbnQgY29sb3I9IiNG RjAwMDAiIHNpemU9IjMiPjxiPqFdw0K6obpJpO6hXjwvYj48L2ZvbnQ+PGZvbnQgY29sb3I9IiNG RjAwMDAiIHNpemU9IjIiPqFDPC9mb250PjwvcD4gICAgICAgICAgICAgICAgIA0KICAgICAgICA8 cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTAwJTsgbWFyZ2luOiAwIj48 Zm9udCBjb2xvcj0iI0ZGMDAwMCIgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD48 L3RkPiAgICAgICAgICAgICAgICANCiAgICA8L3RyPiAgICAgICAgICAgICAgICANCiAgPC90YWJs ZT4gICAgICAgICAgICAgICAgDQo8L2Rpdj4gICAgICAgICAgICAgICAgDQogIDwvY2VudGVyPiAg ICAgICAgICAgICAgICAgICAgDQogIDxkaXYgYWxpZ249ImxlZnQiPiAgDQogICAgPHRhYmxlIGJv cmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iMTA3Ij4gIA0K ICAgICAgPHRyPiAgDQogICAgICAgIDx0ZCB3aWR0aD0iMTA1IiBiZ2NvbG9yPSIjMDA2NjY2Ij4g IA0KICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxNTAl OyBtYXJnaW46IDAiPjxmb250IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIyIj4mbmJzcDsgICANCiAg ICAgICAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiPqxCs/yhQrrCv++k 6KahPC9mb250PjwvdGQ+IA0KICAgICAgPC90cj4gDQogICAgPC90YWJsZT4gDQogIDwvZGl2PiAN CjxjZW50ZXI+ICANCjxkaXYgYWxpZ249ImNlbnRlciI+ICAgICAgICAgICAgIA0KICA8dGFibGUg Ym9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI5NSUiPiAg ICAgICAgICAgICANCiAgICA8dHI+ICAgICAgICAgICAgIA0KICAgICAgPHRkIHdpZHRoPSIxMDAl Ij4gICAgICAgICAgICAgDQogICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUt aGVpZ2h0OiAxMDAlOyBtYXJnaW4tbGVmdDogMDsgbWFyZ2luLXJpZ2h0OiAwOyBtYXJnaW4tdG9w OiAzOyBtYXJnaW4tYm90dG9tOiAwIj48Zm9udCBzaXplPSIyIj61p7jVu1CtsbjVoUOkWr/9qPqq zL3QqMyzV6l3s/io7KFBuU+0waVIsfPFdr3XoUGl0bPGqPqkSK37u7y4yaFDPC9mb250PjwvcD4g ICAgICAgICAgICAgDQogICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVp Z2h0OiAxMDAlOyBtYXJnaW46IDAiPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj4mbmJzcDs8 L2ZvbnQ+PC90ZD4gICAgICAgICAgICAgDQogICAgPC90cj4gICAgICAgICAgICAgDQogIDwvdGFi bGU+ICAgICAgICAgICAgIA0KPC9kaXY+ICAgICAgICAgICAgIA0KICA8L2NlbnRlcj4gICAgICAg ICAgICAgICAgICANCiAgPGRpdiBhbGlnbj0ibGVmdCI+IA0KICAgIDx0YWJsZSBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9IjEwNyI+IA0KICAgICAgPHRy PiANCiAgICAgICAgPHRkIHdpZHRoPSIxMDUiIGJnY29sb3I9IiMwMDY2NjYiPiANCiAgICAgICAg ICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTUwJTsgbWFyZ2luOiAw Ij48Zm9udCBmYWNlPSJBcmlhbCI+Jm5ic3A7ICANCiAgICAgICAgICA8L2ZvbnQ+PGZvbnQgY29s b3I9IiNGRkZGRkYiIHNpemU9IjIiPqxCtkyhQrP4pleuybahPC9mb250PjwvdGQ+IA0KICAgICAg PC90cj4gDQogICAgPC90YWJsZT4gDQogIDwvZGl2PiANCjxjZW50ZXI+ICANCjxkaXYgYWxpZ249 ImNlbnRlciI+ICAgICAgICAgICAgIA0KICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI5NSUiPiAgICAgICAgICAgICANCiAgICA8dHI+ICAg ICAgICAgICAgIA0KICAgICAgPHRkIHdpZHRoPSIxMDAlIj4gICAgICAgICAgICAgDQogICAgICAg IDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW4tbGVm dDogMDsgbWFyZ2luLXJpZ2h0OiAwOyBtYXJnaW4tdG9wOiAzOyBtYXJnaW4tYm90dG9tOiAwIj48 Zm9udCBzaXplPSIyIj62Z6RApty2Z6Stpq2kVzwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJB cmlhbCI+MDk6MDA8L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+ptw8L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iQXJpYWwiPjIxOjUwPC9mb250Pjxmb250IHNpemU9IjIiPqTOtmeku6FCtmek6aatpFc8 L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPjA5OjAwPC9mb250Pjxmb250IHNpemU9 IjIiPqbcPC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj4wNTo1MDwvZm9udD48Zm9u dCBzaXplPSIyIj6hQzwvZm9udD4gICAgICAgICAgICAgDQogICAgICAgIDxwIHN0eWxlPSJ3b3Jk LXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW46IDAiPjxmb250IHNpemU9IjIi IGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+PC90ZD4gICAgICAgICAgICAgDQogICAgPC90cj4g ICAgICAgICAgICAgDQogIDwvdGFibGU+ICAgICAgICAgICAgIA0KPC9kaXY+ICAgICAgICAgICAg IA0KICA8L2NlbnRlcj4gICAgICAgICAgICAgICAgICANCiAgPGRpdiBhbGlnbj0ibGVmdCI+IA0K ICAgIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgd2lk dGg9IjEwNyI+IA0KICAgICAgPHRyPiANCiAgICAgICAgPHRkIHdpZHRoPSIxMDUiIGJnY29sb3I9 IiMwMDY2NjYiPiANCiAgICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhl aWdodDogMTUwJTsgbWFyZ2luOiAwIj48Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiI+Jm5i c3A7ICANCiAgICAgICAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiPqxC sNGhQsO6pebD0qXzPC9mb250PjwvdGQ+IA0KICAgICAgPC90cj4gDQogICAgPC90YWJsZT4gDQog IDwvZGl2PiANCjxjZW50ZXI+ICANCjxkaXYgYWxpZ249ImNlbnRlciI+ICAgICAgICAgICAgIA0K ICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRo PSI5NSUiPiAgICAgICAgICAgICANCiAgICA8dHI+ICAgICAgICAgICAgIA0KICAgICAgPHRkIHdp ZHRoPSIxMDAlIj4gICAgICAgICAgICAgDQogICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6 IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW4tbGVmdDogMDsgbWFyZ2luLXJpZ2h0OiAwOyBt YXJnaW4tdG9wOiAzOyBtYXJnaW4tYm90dG9tOiAwIj48Zm9udCBzaXplPSIyIj6oraX3w9K8dqW7 oUKyprd+w9Ku0bx2pbukzrfTpPmkR7FpoV2kQKZUqc6kR6ZUoV6hQzwvZm9udD4gICAgICAgICAg ICAgDQogICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAl OyBtYXJnaW46IDAiPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+PC90 ZD4gICAgICAgICAgICAgDQogICAgPC90cj4gICAgICAgICAgICAgDQogIDwvdGFibGU+ICAgICAg ICAgICAgIA0KPC9kaXY+ICAgICAgICAgICAgIA0KICA8L2NlbnRlcj4gICAgICAgICAgICAgICAg ICANCiAgPGRpdiBhbGlnbj0ibGVmdCI+IA0KICAgIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9IjQxNiI+IA0KICAgICAgPHRyPiANCiAgICAg ICAgPHRkIHdpZHRoPSIxMDciIGJnY29sb3I9IiMwMDY2NjYiPiANCiAgICAgICAgICA8cCBzdHls ZT0ibGluZS1oZWlnaHQ6IDE1MCU7IHdvcmQtc3BhY2luZzogMDsgbWFyZ2luOiAwIj48Zm9udCBm YWNlPSJBcmlhbCI+Jm5ic3A7ICAgICAgICAgICAgICANCiAgICAgICAgICA8L2ZvbnQ+PGZvbnQg Y29sb3I9IiNGRkZGRkYiIHNpemU9IjIiPqxCuHahQrP4plemYcJJPC9mb250PjwvdGQ+IA0KICAg ICAgICA8dGQgd2lkdGg9IjMwNSI+IA0KICAgICAgICAgIDxwIHN0eWxlPSJsaW5lLWhlaWdodDog MTUwJTsgd29yZC1zcGFjaW5nOiAwOyBtYXJnaW46IDAiPjxmb250IHNpemU9IjIiPqFdsNGm0rr0 p32hRzxmb250IGZhY2U9IkFyaWFsIj48YSBocmVmPSJodHRwOi8vd3d3LmxjY25ldC5jb20udHci IHRhcmdldD0iX2JsYW5rIj53d3cubGNjbmV0LmNvbS50dzwvYT48L2ZvbnQ+oV48L2ZvbnQ+PC90 ZD4gDQogICAgICA8L3RyPiANCiAgICA8L3RhYmxlPiANCiAgPC9kaXY+IA0KPGNlbnRlcj4gIA0K PGRpdiBhbGlnbj0iY2VudGVyIj4gICAgICAgICAgICAgICANCiAgPHRhYmxlIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iOTUlIj4gICAgICAgICAgICAg ICANCiAgICA8dHI+ICAgICAgICAgICAgICAgDQogICAgICA8dGQgd2lkdGg9IjEwMCUiPiAgICAg ICAgICAgICAgIA0KICAgICAgICChQCAgICAgICAgICAgICAgICAgIA0KICA8L2NlbnRlcj4gICAg ICAgICAgICAgICAgIA0KICAgICAgICA8ZGl2IGFsaWduPSJjZW50ZXIiPiAgICAgICAgICAgICAg DQogICAgICAgICAgPHRhYmxlIGJvcmRlcj0iMSIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIwIiB3aWR0aD0iMTAwJSIgYm9yZGVyY29sb3JsaWdodD0iIzgwODA4MCIgYm9yZGVyY29sb3Jk YXJrPSIjRkZGRkZGIj4gICAgICAgICAgICAgIA0KICAgICAgICAgICAgPHRyPiAgICAgICAgICAg ICAgDQogICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTclIiBhbGlnbj0iY2VudGVyIiBiZ2NvbG9y PSIjMzM2Njk5Ij4gICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgIDxwIHN0eWxlPSJ3b3Jk LXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW4tbGVmdDogMjsgbWFyZ2luLXJp Z2h0OiAyOyBtYXJnaW4tdG9wOiAwOyBtYXJnaW4tYm90dG9tOiAwIj48Zm9udCBjb2xvcj0iI0ZG RkZGRiIgc2l6ZT0iMiI+ssSkQLDPsFa9baSkpN88L2ZvbnQ+PC90ZD4gICAgICAgICAgICAgIA0K PGNlbnRlcj4gDQogICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMzIlIiBhbGlnbj0ibGVmdCIgYmdj b2xvcj0iIzMzNjY5OSI+ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICA8cCBzdHlsZT0i d29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTAwJTsgbWFyZ2luLWxlZnQ6IDI7IG1hcmdp bi1yaWdodDogMjsgbWFyZ2luLXRvcDogMDsgbWFyZ2luLWJvdHRvbTogMCI+PGZvbnQgY29sb3I9 IiNGRkZGRkYiIHNpemU9IjIiPiZuYnNwO6V4pV+lq6m+p7WqRrj0PC9mb250Pjxmb250IGNvbG9y PSIjRkZGRkZGIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+NDwvZm9udD48Zm9udCBjb2xvcj0iI0ZG RkZGRiIgc2l6ZT0iMiI+rHE8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiIGZh Y2U9IkFyaWFsIj4xNzY8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiPri5PC9m b250Pjxmb250IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+NDwvZm9udD48 Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiI+vNM8L2ZvbnQ+PC90ZD4gICAgICAgICAgICAg IA0KICA8L2NlbnRlcj4gICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICA8dGQgd2lkdGg9 IjIwJSIgYmdjb2xvcj0iIzMzNjY5OSI+ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICA8 cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTAwJTsgbWFyZ2luLWxlZnQ6 IDI7IG1hcmdpbi1yaWdodDogMjsgbWFyZ2luLXRvcDogMDsgbWFyZ2luLWJvdHRvbTogMCI+PGZv bnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiIGZhY2U9IkFyaWFsIj5URUw6MDItMjc0MDM4NjI8 L2ZvbnQ+PC90ZD4gICAgICAgICAgICAgIA0KICAgICAgICAgICAgICA8dGQgd2lkdGg9IjMxJSIg Ymdjb2xvcj0iIzMzNjY5OSI+ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICA8cCBzdHls ZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTAwJTsgbWFyZ2luLWxlZnQ6IDI7IG1h cmdpbi1yaWdodDogMjsgbWFyZ2luLXRvcDogMDsgbWFyZ2luLWJvdHRvbTogMCI+PGZvbnQgY29s b3I9IiNGRkZGRkYiIHNpemU9IjIiPrG2uUKpvqe1tLCkxq+4M7i5pVikZqFBPC9mb250Pjxmb250 IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+TkVUPC9mb250Pjxmb250IGNv bG9yPSIjRkZGRkZGIiBzaXplPSIyIj6qQbmiPC9mb250Pjxmb250IGNvbG9yPSIjRkZGRkZGIiBz aXplPSIyIj6806RXPC9mb250PjwvdGQ+ICAgICAgICAgICAgICANCiAgICAgICAgICAgIDwvdHI+ ICAgICAgICAgICAgICANCjxjZW50ZXI+IA0KICAgICAgICAgICAgPHRyPiAgICAgICAgICAgICAg DQogICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTclIiBhbGlnbj0iY2VudGVyIiBiZ2NvbG9yPSIj MzM2Njk5Ij4gICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNw YWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW4tbGVmdDogMjsgbWFyZ2luLXJpZ2h0 OiAyOyBtYXJnaW4tdG9wOiAwOyBtYXJnaW4tYm90dG9tOiAwIj48Zm9udCBjb2xvcj0iI0ZGRkZG RiIgc2l6ZT0iMiI+ssSkR7DPsFa9baSkpN88L2ZvbnQ+PC90ZD4gICAgICAgICAgICAgIA0KICAg ICAgICAgICAgICA8dGQgd2lkdGg9IjMyJSIgYWxpZ249ImxlZnQiIGJnY29sb3I9IiMzMzY2OTki PiAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzog MDsgbGluZS1oZWlnaHQ6IDEwMCU7IG1hcmdpbi1sZWZ0OiAyOyBtYXJnaW4tcmlnaHQ6IDI7IG1h cmdpbi10b3A6IDA7IG1hcmdpbi1ib3R0b206IDAiPjxmb250IGNvbG9yPSIjRkZGRkZGIiBzaXpl PSIyIj4mbmJzcDuleKVfpavAXatluPQ8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9 IjIiIGZhY2U9IkFyaWFsIj4zNjwvZm9udD48Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiI+ uLk8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiIGZhY2U9IkFyaWFsIj40PC9m b250Pjxmb250IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIyIj680zwvZm9udD48L3RkPiAgICAgICAg ICAgICAgDQogIDwvY2VudGVyPiAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgIDx0ZCB3 aWR0aD0iMjAlIiBiZ2NvbG9yPSIjMzM2Njk5Ij4gICAgICAgICAgICAgIA0KICAgICAgICAgICAg ICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW4t bGVmdDogMjsgbWFyZ2luLXJpZ2h0OiAyOyBtYXJnaW4tdG9wOiAwOyBtYXJnaW4tYm90dG9tOiAw Ij48Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPiAgICAgICAgICAg ICAgICAgIFRFTDowMi0yMzg5NjU3NzwvZm9udD48L3RkPiAgICAgICAgICAgICAgDQo8Y2VudGVy PiANCiAgICAgICAgICAgICAgPHRkIHdpZHRoPSIzMSUiIGJnY29sb3I9IiMzMzY2OTkiPiAgICAg ICAgICAgICAgDQogICAgICAgICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGlu ZS1oZWlnaHQ6IDEwMCU7IG1hcmdpbi1sZWZ0OiAyOyBtYXJnaW4tcmlnaHQ6IDI7IG1hcmdpbi10 b3A6IDA7IG1hcmdpbi1ib3R0b206IDAiPjxmb250IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIyIj6l eKVfpPWorq+4q2WhQaRnpmG7yKbmrsehQaSmtKOpQLDYvNOkVzwvZm9udD48L3RkPiAgICAgICAg ICAgICAgDQogICAgICAgICAgICA8L3RyPiAgICAgICAgICAgICAgDQogICAgICAgICAgICA8dHI+ ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgPHRkIHdpZHRoPSIxNyUiIGFsaWduPSJjZW50 ZXIiIGJnY29sb3I9IiMzMzY2OTkiPiAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgPHAg c3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDEwMCU7IG1hcmdpbi1sZWZ0OiAy OyBtYXJnaW4tcmlnaHQ6IDI7IG1hcmdpbi10b3A6IDA7IG1hcmdpbi1ib3R0b206IDAiPjxmb250 IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIyIj6yxKS7sM+wVr1tpKSk3zwvZm9udD48L3RkPiAgICAg ICAgICAgICAgDQogICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMzIlIiBhbGlnbj0ibGVmdCIgYmdj b2xvcj0iIzMzNjY5OSI+ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICA8cCBzdHlsZT0i d29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTAwJTsgbWFyZ2luLWxlZnQ6IDI7IG1hcmdp bi1yaWdodDogMjsgbWFyZ2luLXRvcDogMDsgbWFyZ2luLWJvdHRvbTogMCI+PGZvbnQgY29sb3I9 IiNGRkZGRkYiIHNpemU9IjIiPiZuYnNwO6V4pV+lq8O5tLW61rj0PC9mb250Pjxmb250IGNvbG9y PSIjRkZGRkZGIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+NDwvZm9udD48Zm9udCBjb2xvcj0iI0ZG RkZGRiIgc2l6ZT0iMiI+rHE8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiIGZh Y2U9IkFyaWFsIj42NDwvZm9udD48Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiI+uLk8L2Zv bnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiIGZhY2U9IkFyaWFsIj40PC9mb250Pjxm b250IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIyIj680zwvZm9udD48L3RkPiAgICAgICAgICAgICAg DQogIDwvY2VudGVyPiAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgIDx0ZCB3aWR0aD0i MjAlIiBiZ2NvbG9yPSIjMzM2Njk5Ij4gICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgIDxw IHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW4tbGVmdDog MjsgbWFyZ2luLXJpZ2h0OiAyOyBtYXJnaW4tdG9wOiAwOyBtYXJnaW4tYm90dG9tOiAwIj48Zm9u dCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPiAgICAgICAgICAgIFRFTDow Mi0yMzY0ODg4NTwvZm9udD48L3RkPiAgICAgICAgICAgICAgDQo8Y2VudGVyPiANCiAgICAgICAg ICAgICAgPHRkIHdpZHRoPSIzMSUiIGJnY29sb3I9IiMzMzY2OTkiPiAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDEw MCU7IG1hcmdpbi1sZWZ0OiAyOyBtYXJnaW4tcmlnaHQ6IDI7IG1hcmdpbi10b3A6IDA7IG1hcmdp bi1ib3R0b206IDAiPjxmb250IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIyIj6xtrlCpL3AXa+4Mbi5 pVikZqWqwuChQTwvZm9udD48Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiIgZmFjZT0iQXJp YWwiPk5FVDwvZm9udD48Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiI+qkG5orzTpFc8L2Zv bnQ+PC90ZD4gICAgICAgICAgICAgIA0KICAgICAgICAgICAgPC90cj4gICAgICAgICAgICAgIA0K ICAgICAgICAgICAgPHRyPiAgICAgICAgICAgICAgDQogICAgICAgICAgICAgIDx0ZCB3aWR0aD0i MTclIiBhbGlnbj0iY2VudGVyIiBiZ2NvbG9yPSIjMzM2Njk5Ij4gICAgICAgICAgICAgIA0KICAg ICAgICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAl OyBtYXJnaW4tbGVmdDogMjsgbWFyZ2luLXJpZ2h0OiAyOyBtYXJnaW4tdG9wOiAwOyBtYXJnaW4t Ym90dG9tOiAwIj48Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiI+ssSkRbDPsFa9baSkpN88 L2ZvbnQ+PC90ZD4gICAgICAgICAgICAgIA0KICAgICAgICAgICAgICA8dGQgd2lkdGg9IjMyJSIg YWxpZ249ImxlZnQiIGJnY29sb3I9IiMzMzY2OTkiPiAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDEwMCU7IG1hcmdp bi1sZWZ0OiAyOyBtYXJnaW4tcmlnaHQ6IDI7IG1hcmdpbi10b3A6IDA7IG1hcmdpbi1ib3R0b206 IDAiPjxmb250IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIyIj4mbmJzcDuwqravpau3c7+zsM+kpKRz pEC49DwvZm9udD48Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPjI1 My0xPC9mb250Pjxmb250IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIyIj64uTwvZm9udD48Zm9udCBj b2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPjE8L2ZvbnQ+PGZvbnQgY29sb3I9 IiNGRkZGRkYiIHNpemU9IjIiPrzTPC9mb250PjwvdGQ+ICAgICAgICAgICAgICANCiAgPC9jZW50 ZXI+ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgPHRkIHdpZHRoPSIyMCUiIGJnY29s b3I9IiMzMzY2OTkiPiAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgPHAgc3R5bGU9Indv cmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDEwMCU7IG1hcmdpbi1sZWZ0OiAyOyBtYXJnaW4t cmlnaHQ6IDI7IG1hcmdpbi10b3A6IDA7IG1hcmdpbi1ib3R0b206IDAiPjxmb250IGNvbG9yPSIj RkZGRkZGIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+VEVMOjA3LTI4MjI2MjY8L2ZvbnQ+PC90ZD4g ICAgICAgICAgICAgIA0KPGNlbnRlcj4gDQogICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMzElIiBi Z2NvbG9yPSIjMzM2Njk5Ij4gICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgIDxwIHN0eWxl PSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW4tbGVmdDogMjsgbWFy Z2luLXJpZ2h0OiAyOyBtYXJnaW4tdG9wOiAwOyBtYXJnaW4tYm90dG9tOiAwIj48Zm9udCBjb2xv cj0iI0ZGRkZGRiIgc2l6ZT0iMiI+sKq2r6T1qK6vuKtloUGq8aRLvHe49KFBqvel27DzrtGnva7H PC9mb250PjwvdGQ+ICAgICAgICAgICAgICANCiAgICAgICAgICAgIDwvdHI+ICAgICAgICAgICAg ICANCiAgICAgICAgICA8L3RhYmxlPiAgICAgICAgICAgICAgDQogICAgICAgIDwvZGl2PiAgICAg ICAgICAgICAgDQogICAgICA8L2NlbnRlcj48L3RkPiAgICAgICAgICAgIA0KICAgIDwvdHI+ICAg ICAgICAgICAgDQogIDwvdGFibGU+ICAgICAgICAgICAgDQo8L2Rpdj4gICAgICAgICAgICANCjxm b3JtIG1ldGhvZD0iUE9TVCIgYWN0aW9uPSJodHRwOi8vNjEuMTYuMTEuMjQzL3NlbmRtYWlsLmFz cCIgb25TdWJtaXQ9IiIgbmFtZT0iZm9ybTEiPiAgICAgICAgICAgIA0KICA8aHIgc2l6ZT0iMSIg Y29sb3I9IiMwMDgwMDAiPiAgICAgICAgICAgIA0KICA8ZGl2IGFsaWduPSJjZW50ZXIiPiAgICAg ICAgICAgIA0KICAgIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMSIgd2lkdGg9Ijk1JSIgaGVpZ2h0PSIxODAiPiAgICAgICAgICAgIA0KICAgICAgPHRyPiAg ICAgICAgICAgIA0KICAgICAgICA8dGQgd2lkdGg9IjEwMCUiIGhlaWdodD0iMjUiIGFsaWduPSJy aWdodCIgYmdjb2xvcj0iIzAwMDAwMCIgY29sc3Bhbj0iMiI+ICAgICAgICAgICAgDQogICAgICAg ICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDE1MCU7IG1hcmdpbi1s ZWZ0OiA1OyBtYXJnaW4tcmlnaHQ6IDU7IG1hcmdpbi10b3A6IDM7IG1hcmdpbi1ib3R0b206IDMi IGFsaWduPSJjZW50ZXIiPjxmb250IGNvbG9yPSIjRkZGRkZGIj65dyZuYnNwOyZuYnNwOyAgIA0K ICAgICAgICAgIKz5Jm5ic3A7Jm5ic3A7ILP4Jm5ic3A7Jm5ic3A7IKZXJm5ic3A7Jm5ic3A7ILVu Jm5ic3A7Jm5ic3A7ICAgDQogICAgICAgICAgsE8mbmJzcDsmbmJzcDsgqu08L2ZvbnQ+PC90ZD4g ICAgICAgICAgICAgIA0KICAgICAgPC90cj4gICAgICAgICAgICAgIA0KICAgICAgPHRyPiAgICAg ICAgICAgICAgDQogICAgICAgIDx0ZCB3aWR0aD0iMTklIiBoZWlnaHQ9IjI1IiBhbGlnbj0icmln aHQiIGJnY29sb3I9IiNDQ0ZGQ0MiPiAgICAgICAgICAgICAgDQogICAgICAgICAgPHAgc3R5bGU9 IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDEwMCU7IG1hcmdpbjogMCI+PGZvbnQgc2l6 ZT0iMiI+sNGlW6RIrfuhRzwvZm9udD48L3RkPiAgICAgICAgICAgICAgDQogICAgICAgIDx0ZCB3 aWR0aD0iODElIiBoZWlnaHQ9IjI1IiBiZ2NvbG9yPSIjQ0NGRkNDIj4gICAgICAgICAgICAgIA0K ICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBt YXJnaW46IDAiPjxmb250IHNpemU9IjIiPiZuYnNwOzxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJu YW1lIiBzaXplPSIyMCI+PC9mb250PjwvdGQ+ICAgICAgICAgICAgICANCiAgICAgIDwvdHI+ICAg ICAgICAgICAgICANCiAgICAgIDx0cj4gICAgICAgICAgICAgIA0KICAgICAgICA8dGQgd2lkdGg9 IjE5JSIgaGVpZ2h0PSIyMyIgYWxpZ249InJpZ2h0IiBiZ2NvbG9yPSIjRkZGRkNDIj4gICAgICAg ICAgICAgIA0KICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0 OiAxMDAlOyBtYXJnaW46IDAiPjxmb250IHNpemU9IjIiPqVYpc2mfqTrpOmhRzwvZm9udD48L3Rk PiAgICAgICAgICAgICAgDQogICAgICAgIDx0ZCB3aWR0aD0iODElIiBoZWlnaHQ9IjIzIiBiZ2Nv bG9yPSIjRkZGRkNDIj4gICAgICAgICAgICAgIA0KICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNw YWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW46IDAiPjxmb250IHNpemU9IjIiPiZu YnNwOzxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJteWVhciIgc2l6ZT0iNSI+pn48aW5wdXQgdHlw ZT0idGV4dCIgbmFtZT0ibW1vbiIgc2l6ZT0iNSI+pOs8aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0i bWRheSIgc2l6ZT0iNSI+pOk8L2ZvbnQ+PC90ZD4gICAgICAgICAgICAgIA0KICAgICAgPC90cj4g ICAgICAgICAgICAgIA0KICAgICAgPHRyPiAgICAgICAgICAgICAgDQogICAgICAgIDx0ZCB3aWR0 aD0iMTklIiBoZWlnaHQ9IjIyIiBhbGlnbj0icmlnaHQiIGJnY29sb3I9IiNDQ0ZGQ0MiPiAgICAg ICAgICAgICAgDQogICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWln aHQ6IDEwMCU7IG1hcmdpbjogMCI+PGZvbnQgc2l6ZT0iMiI+qcqhQKFAp0+hRzwvZm9udD48L3Rk PiAgICAgICAgICAgICAgDQogICAgICAgIDx0ZCB3aWR0aD0iODElIiBoZWlnaHQ9IjIyIiBiZ2Nv bG9yPSIjQ0NGRkNDIj4gICAgICAgICAgICAgIA0KICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNw YWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW46IDAiPjxmb250IHNpemU9IjIiPiZu YnNwOzxpbnB1dCB0eXBlPSJyYWRpbyIgdmFsdWU9Iqhrpc0iIG5hbWU9InNleCIgY2hlY2tlZD6l /aXNPGlucHV0IHR5cGU9InJhZGlvIiBuYW1lPSJzZXgiIHZhbHVlPSKka6XNIj6kcKlqPC9mb250 PjwvdGQ+ICAgICAgICAgICAgICANCiAgICAgIDwvdHI+ICAgICAgICAgICAgICANCiAgICAgIDx0 cj4gICAgICAgICAgICAgIA0KICAgICAgICA8dGQgd2lkdGg9IjE5JSIgaGVpZ2h0PSIyMiIgYWxp Z249InJpZ2h0IiBiZ2NvbG9yPSIjRkZGRkNDIj4gICAgICAgICAgICAgIA0KICAgICAgICAgIDxw IHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxpbmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW46IDAiPjxm b250IHNpemU9IjIiPrPMsKq+x776oUc8L2ZvbnQ+PC90ZD4gICAgICAgICAgICAgIA0KICAgICAg ICA8dGQgd2lkdGg9IjgxJSIgaGVpZ2h0PSIyMiIgYmdjb2xvcj0iI0ZGRkZDQyI+ICAgICAgICAg ICAgICANCiAgICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDog MTAwJTsgbWFyZ2luOiAwIj4mbmJzcDs8c2VsZWN0IHNpemU9IjEiIG5hbWU9ImdyYXVkZSI+ICAg ICAgICAgICAgIA0KICAgICAgICAgICAgPG9wdGlvbiB2YWx1ZT0isKqkpMK+Ij6wqqSkwr48L29w dGlvbj4gICAgICAgICAgIA0KICAgICAgICAgICAgPG9wdGlvbiB2YWx1ZT0ipGqxTSI+pGqxTTwv b3B0aW9uPiAgICAgICAgICAgDQogICAgICAgICAgICA8b3B0aW9uIHZhbHVlPSKkar7HIj6kar7H PC9vcHRpb24+ICAgICAgICAgICANCiAgICAgICAgICA8L3NlbGVjdD48L3RkPiAgICAgICAgICAg DQogICAgICA8L3RyPiAgICAgICAgICAgDQogICAgICA8dHI+ICAgICAgICAgICANCiAgICAgICAg PHRkIHdpZHRoPSIxOSUiIGhlaWdodD0iMjIiIGFsaWduPSJyaWdodCIgYmdjb2xvcj0iI0NDRkZD QyI+ICAgICAgICAgICANCiAgICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5l LWhlaWdodDogMTAwJTsgbWFyZ2luOiAwIj48Zm9udCBzaXplPSIyIj6zc7W4uXG43KFHPC9mb250 PjwvdGQ+ICAgICAgICAgICANCiAgICAgICAgPHRkIHdpZHRoPSI4MSUiIGhlaWdodD0iMjIiIGJn Y29sb3I9IiNDQ0ZGQ0MiPiAgICAgICAgICAgDQogICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3Bh Y2luZzogMDsgbGluZS1oZWlnaHQ6IDEwMCU7IG1hcmdpbjogMCI+PGZvbnQgc2l6ZT0iMiI+Jm5i c3A7PGlucHV0IHR5cGU9InRleHQiIG5hbWU9InRlbDEiIHNpemU9IjUiPjwvZm9udD48Zm9udCBz aXplPSIyIiBmYWNlPSJBcmlhbCI+LTwvZm9udD48Zm9udCBzaXplPSIyIj48aW5wdXQgdHlwZT0i dGV4dCIgbmFtZT0idGVsMiIgc2l6ZT0iMTgiPjwvZm9udD48L3RkPiAgICAgICAgICAgDQogICAg ICA8L3RyPiAgICAgICAgICAgDQogICAgICA8dHI+ICAgICAgICAgICANCiAgICAgICAgPHRkIHdp ZHRoPSIxOSUiIGhlaWdodD0iMjIiIGFsaWduPSJyaWdodCIgYmdjb2xvcj0iI0ZGRkZDQyI+ICAg ICAgICAgICANCiAgICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdo dDogMTAwJTsgbWFyZ2luOiAwIj48Zm9udCBzaXplPSIyIj6zc7W4pmGnfaFHPC9mb250PjwvdGQ+ ICAgICAgICAgICANCiAgICAgICAgPHRkIHdpZHRoPSI4MSUiIGhlaWdodD0iMjIiIGJnY29sb3I9 IiNGRkZGQ0MiPiAgICAgICAgICAgDQogICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzog MDsgbGluZS1oZWlnaHQ6IDEwMCU7IG1hcmdpbjogMCI+PGZvbnQgc2l6ZT0iMiI+Jm5ic3A7PGlu cHV0IHR5cGU9InRleHQiIG5hbWU9ImFkZCIgc2l6ZT0iNTQiPjwvZm9udD48L3RkPiAgICAgICAg ICAgDQogICAgICA8L3RyPiAgICAgICAgICAgDQogICAgICA8dHI+ICAgICAgICAgICANCiAgICAg ICAgPHRkIHdpZHRoPSIxOSUiIGhlaWdodD0iMjIiIGFsaWduPSJyaWdodCIgYmdjb2xvcj0iI0ND RkZDQyI+ICAgICAgICAgICANCiAgICAgICAgICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBs aW5lLWhlaWdodDogMTAwJTsgbWFyZ2luOiAwIj48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+ RS1NYWlsPC9mb250Pjxmb250IHNpemU9IjIiPqFHPC9mb250PjwvdGQ+ICAgICAgICAgICANCiAg ICAgICAgPHRkIHdpZHRoPSI4MSUiIGhlaWdodD0iMjIiIGJnY29sb3I9IiNDQ0ZGQ0MiPiAgICAg ICAgICAgDQogICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6 IDEwMCU7IG1hcmdpbjogMCI+PGZvbnQgc2l6ZT0iMiI+Jm5ic3A7PGlucHV0IHR5cGU9InRleHQi IG5hbWU9Im1haWwiIHNpemU9IjM5Ij48L2ZvbnQ+PC90ZD4gICAgICAgICAgIA0KICAgICAgPC90 cj4gICAgICAgICAgIA0KICAgICAgPHRyPiAgICAgICAgICAgDQogICAgICAgIDx0ZCB3aWR0aD0i MTklIiBoZWlnaHQ9IjIyIiBhbGlnbj0icmlnaHQiIGJnY29sb3I9IiNGRkZGQ0MiPiAgICAgICAg ICAgDQogICAgICAgICAgPHAgc3R5bGU9IndvcmQtc3BhY2luZzogMDsgbGluZS1oZWlnaHQ6IDEw MCU7IG1hcmdpbi1sZWZ0OiAwOyBtYXJnaW4tcmlnaHQ6IDA7IG1hcmdpbi10b3A6IDU7IG1hcmdp bi1ib3R0b206IDUiPjxmb250IHNpemU9IjIiPrH9sNGlW69ap0+hRzwvZm9udD48L3RkPiAgICAg ICAgICAgDQogICAgICAgIDx0ZCB3aWR0aD0iODElIiBoZWlnaHQ9IjIyIiBiZ2NvbG9yPSIjRkZG RkNDIj4gICAgICAgICAgIA0KICAgICAgICAgIDxwIHN0eWxlPSJ3b3JkLXNwYWNpbmc6IDA7IGxp bmUtaGVpZ2h0OiAxMDAlOyBtYXJnaW4tbGVmdDogMDsgbWFyZ2luLXJpZ2h0OiAwOyBtYXJnaW4t dG9wOiA1OyBtYXJnaW4tYm90dG9tOiA1Ij48Zm9udCBzaXplPSIyIj4mbmJzcDs8aW5wdXQgdHlw ZT0icmFkaW8iIHZhbHVlPSK1e6ahs12tcK9aIiBuYW1lPSJjbGFzcyIgY2hlY2tlZD61e6ahs12t cK9aPGlucHV0IHR5cGU9InJhZGlvIiB2YWx1ZT0iuvS72rr0uPS46q7Grne1e6ahs12tcCIgbmFt ZT0iY2xhc3MiPrr0u9q69Lj0uOquxq53tXumobNdrXA8aW5wdXQgdHlwZT0icmFkaW8iIHZhbHVl PSK46q7Grne1e6ahs12tcK9aIiBuYW1lPSJjbGFzcyI+uOquxq53tXumobNdrXCvWjwvZm9udD48 L3RkPiAgICAgICAgICAgDQogICAgICA8L3RyPiAgICAgICAgICAgDQogICAgICA8dHI+ICAgICAg ICAgICANCiAgICAgICAgPHRkIHdpZHRoPSIxOSUiIGhlaWdodD0iMjIiIGFsaWduPSJyaWdodCIg Ymdjb2xvcj0iI0NDRkZDQyI+ICAgICAgICAgICANCiAgICAgICAgICA8cCBzdHlsZT0ibWFyZ2lu LXRvcDogNTsgbWFyZ2luLWJvdHRvbTogNSI+PGZvbnQgc2l6ZT0iMiI+sf2kV73SpmHCSaFHPC9m b250PjwvdGQ+ICAgICAgICAgIA0KICAgICAgICA8dGQgd2lkdGg9IjgxJSIgaGVpZ2h0PSIyMiIg Ymdjb2xvcj0iI0NDRkZDQyI+ICAgICAgICAgIA0KICAgICAgICAgIDxwIHN0eWxlPSJtYXJnaW4t dG9wOiA1OyBtYXJnaW4tYm90dG9tOiA1Ij48Zm9udCBzaXplPSIyIj4mbmJzcDs8aW5wdXQgdHlw ZT0icmFkaW8iIG5hbWU9InBvaW50IiB2YWx1ZT0iqb6ntaTArtUiIGNoZWNrZWQ+ssSkQLDPoUA8 aW5wdXQgdHlwZT0icmFkaW8iIG5hbWU9InBvaW50IiB2YWx1ZT0iwF2rZaTArtUiPrLEpEewz6FA PGlucHV0IHR5cGU9InJhZGlvIiBuYW1lPSJwb2ludCIgdmFsdWU9IqS9wF2kwK7VIj6yxKS7sM+h QDxpbnB1dCB0eXBlPSJyYWRpbyIgbmFtZT0icG9pbnQiIHZhbHVlPSKwqravpMCu1SI+ssSkRbDP PC9mb250PjwvdGQ+ICAgICAgICAgDQogICAgICA8L3RyPiAgICAgICAgIA0KICAgIDwvdGFibGU+ ICAgICAgICAgDQogIDwvZGl2PiAgICAgICAgIA0KICA8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAw OyBsaW5lLWhlaWdodDogMTAwJTsgbWFyZ2luLWxlZnQ6IDU7IG1hcmdpbi1yaWdodDogNTsgbWFy Z2luLXRvcDogMDsgbWFyZ2luLWJvdHRvbTogMCIgYWxpZ249ImNlbnRlciI+PGlucHV0IHR5cGU9 ImJ1dHRvbiIgdmFsdWU9IrBlpVi46q7GIiBuYW1lPSJCMSIgb25jbGljaz0iZGF0YWNoZWNrKCki PqFAPGlucHV0IHR5cGU9InJlc2V0IiB2YWx1ZT0irau3c7bxvGciIG5hbWU9IkIyIj48L3A+ICAg ICAgICAgDQo8L2Zvcm0+ICAgICAgICAgDQo8ZGl2IGFsaWduPSJjZW50ZXIiPiAgICAgICAgIA0K ICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRo PSI5NSUiPiAgICAgICAgIA0KICAgIDx0cj4gICAgICAgICANCiAgICAgIDx0ZCB3aWR0aD0iMTQl IiB2YWxpZ249InRvcCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiNGRjAwMDAiPqpgt06oxra1oUc8 L2ZvbnQ+PC90ZD4gICAgICAgICANCiAgICAgIDx0ZCB3aWR0aD0iODYlIiB2YWxpZ249InRvcCI+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwRkYiPqG2pFq5d6z5s/imV6vhoUGkpKTfsU7AdaX9 q0+vZKZXw0KhQb3QqfO5d6z5tW6wT6vhpEek6aS6oUGm3KRXrXqz+KZXpmHCSbDRpVu6wrjVoUM8 L2ZvbnQ+PC90ZD4gICAgICAgICANCiAgICA8L3RyPiAgICAgICAgIA0KICAgIDx0cj4gICAgICAg ICANCiAgICAgIDx0ZCB3aWR0aD0iMTQlIiB2YWxpZ249InRvcCI+PC90ZD4gICAgICAgICANCiAg ICAgIDx0ZCB3aWR0aD0iODYlIiB2YWxpZ249InRvcCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMw MDAwRkYiPqG2pnCmuavKbWFpbLN5pqixeqq6p3jCWr3Qpl6rSKdpqr4sp9qtzLFOt3ynUrCjsXqq urjqrsahQzwvZm9udD48L3RkPiAgICAgICAgIA0KICAgIDwvdHI+ICAgICAgICAgDQogIDwvdGFi bGU+ICAgICAgICAgDQo8L2Rpdj4gICAgICAgICANCjwvdGQ+PC90cj48L3RhYmxlPiAgICAgICAg ICAgICAgICAgDQo8cCBzdHlsZT0id29yZC1zcGFjaW5nOiAwOyBsaW5lLWhlaWdodDogMTUwJTsg bWFyZ2luOiAwIj6hQDwvdGQ+PC90cj48L3RhYmxlPjwvZGl2PiAgICAgICAgICAgICAgICAgDQo8 U2NyaXB0IExhbmd1YWdlPVZCc2NyaXB0PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgRnVuY3Rpb24gZGF0YWNoZWNrICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg ICAgICAgICAgICBkaW0gZXJyZmxhZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgIGVycmZsYWcg PSBUcnVlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgJ8DLrGQgrE+nX6ywoXWq xaZypuqhdiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgIElmIChmb3JtMS5uYW1lLnZhbHVlID0g RW1wdHkpIHRoZW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAg ICAgICAgICAgTXNnQm94ICKpbaZXoUGko6Vpv+mkSqrFpdWhSSIsIDY0LCAisFSup6FJIiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAg ICAgICAgICAgICAgZm9jdXN0bygwKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIGVycmZs YWcgPSBGYWxzZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgRXhpdCBGdW5jdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgRW5kIGlmICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgSWYgKGZvcm0xLm15ZWFyLnZhbHVlID0gRW1wdHkpIHRoZW4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgTXNnQm94 ICKlWKXNpOmquqZ+pfehQaSjpWm/6aRKqsWl1aFJIiwgNjQsICKwVK6noUkiICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg ICAgICBmb2N1c3RvKDEpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgZXJyZmxhZyA9IEZh bHNlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgICAgICAgICBFeGl0IEZ1bmN0aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICBFbmQgaWYgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgDQogICAgICAg ICAgICAgICAgIElmIChmb3JtMS5tbW9uLnZhbHVlID0gRW1wdHkpIHRoZW4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgTXNnQm94ICKlWKXNpOmq uqTrpfehQaSjpWm/6aRKqsWl1aFJIiwgNjQsICKwVK6noUkiICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICBmb2N1 c3RvKDIpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgZXJyZmxhZyA9IEZhbHNlICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAg ICBFeGl0IEZ1bmN0aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgICAgICBFbmQgaWYgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgDQogICAgICAgICAgICAgICAg IElmIChmb3JtMS5tZGF5LnZhbHVlID0gRW1wdHkpIHRoZW4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgTXNnQm94ICKlWKXNpOmquqTRvMahQaSj pWm/6aRKqsWl1aFJIiwgNjQsICKwVK6noUkiICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICBmb2N1c3RvKDMpICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgZXJyZmxhZyA9IEZhbHNlICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICBFeGl0IEZ1 bmN0aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KICAgICAgICAgICAgICAgICBFbmQgaWYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICBJZiAoZm9y bTEudGVsMS52YWx1ZSA9IEVtcHR5KSB0aGVuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQogICAgICAgICAgICAgICAgICAgIE1zZ0JveCAiwXC1uLlxuNyqurDPsOy9WKFBpKOlab/p pEqqxaXVoUkiLCA2NCwgIrBUrqehSSIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIGZvY3VzdG8oNykgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KICAgICAgICAgICAgICAgICAgICBlcnJmbGFnID0gRmFsc2UgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIEV4aXQgRnVuY3Rp b24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgICAgIEVuZCBpZiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgIElmIChmb3JtMS50 ZWwyLnZhbHVlID0gRW1wdHkpIHRoZW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgTXNnQm94ICLBcLW4uXG43KFBpKOlab/ppEqqxaXVoUkiLCA2 NCwgIrBUrqehSSIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQogICAgICAgICAgICAgICAgICAgIGZvY3VzdG8oOCkgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgICAgICAgICBlcnJmbGFnID0gRmFsc2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIEV4aXQgRnVuY3Rpb24gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgIEVuZCBpZiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgIElmIChmb3JtMS5hZGQudmFsdWUgPSBF bXB0eSkgdGhlbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg ICAgICAgICBNc2dCb3ggIsFwtbimYad9oUGko6Vpv+mkSqrFpdWhSSIsIDY0LCAisFSup6FJIiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAgICAgICAgICAgZm9jdXN0byg5KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIGVy cmZsYWcgPSBGYWxzZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgRXhpdCBGdW5jdGlvbiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgRW5kIGlmICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCiAgICAgICAgICAgICAgICAgSWYgKGZvcm0xLm1haWwudmFsdWUgPSBFbXB0eSkgdGhlbiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICBNc2dC b3ggIrlxpGy2bKXzoUGko6Vpv+mkSqrFpdWhSSIsIDY0LCAisFSup6FJIiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgZm9jdXN0bygxMCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICBlcnJmbGFnID0gRmFs c2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgICAgICAgIEV4aXQgRnVuY3Rpb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgIEVuZCBpZiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAg ICAgICAgICAgIGRhdGFjaGVjayA9IGVycmZsYWcgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICdTdWJtaXQotsewZSmq7bPm uOquxqbcV2ViIFNlcnZlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgICAgICAgICAgICAgICAgZm9ybTEuU3VibWl0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICBFbmQgRnVuY3Rpb24g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAg IFN1YiBmb2N1c3RvKHgpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgJ7FOtOW80Kl3puyp86xZrdPE5qbsICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgZG9j dW1lbnQuZm9ybTEuZWxlbWVudHMoeCkuZm9jdXMoKSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgRW5kIFN1YiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo8L1Njcmlw dD4gICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgDQo8L2JvZHk+ICAgICAgICAg ICAgICAgICANCjwvaHRtbD4= ------=_NextPart_yZNwfFJIk6XxQT65OJsAA-- ------=_NextPart_yZNwfFJIk6XxQT65OJs-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 7:40: 2 2001 Delivered-To: freebsd-security@freebsd.org Received: from dolphin.idleplay.net (cx344940-a.meta1.la.home.com [24.6.21.74]) by hub.freebsd.org (Postfix) with ESMTP id B758337B417 for ; Wed, 8 Aug 2001 07:39:56 -0700 (PDT) (envelope-from conrads@dolphin.idleplay.net) Received: (from conrads@localhost) by dolphin.idleplay.net (8.11.5/8.11.4) id f789eZ910628; Wed, 8 Aug 2001 09:40:35 GMT (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010805223127.A4779@mandark.attica.home> Date: Wed, 08 Aug 2001 09:40:35 -0000 (GMT) Organization: @Home Network From: Conrad Sabatier To: Andre Goeree Subject: RE: multiple port scans: tcp/8888 Cc: security@FreeBSD.ORG 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 05-Aug-2001 Andre Goeree wrote: > Hello -security, > > Attached is part of my ipfilter log. The file shows port scans coming > in from 25 different IP addresses from all over the world (Europe, > USA, Asia) to tcp/8888. Since I could not find any information about > tcp/8888, any comments are appreciated. > > Ago. Port 8888 is used by the OpenNap (Napster clone) server. I'd say this is most likely what people are looking for. -- Conrad Sabatier conrads@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 8: 9:32 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.wlcg.com (unknown [198.92.199.5]) by hub.freebsd.org (Postfix) with ESMTP id 9B32137B403 for ; Wed, 8 Aug 2001 08:09:21 -0700 (PDT) (envelope-from rsimmons@wlcg.com) Received: (from root@localhost) by mail.wlcg.com (8.11.4/8.11.4) id f78F9iM21343 for freebsd-security@freebsd.org; Wed, 8 Aug 2001 11:09:44 -0400 (EDT) (envelope-from rsimmons@wlcg.com) Received: from localhost (rsimmons@localhost) by mail.wlcg.com (8.11.4/8.11.4av) with ESMTP id f78F9gI21334 for ; Wed, 8 Aug 2001 11:09:43 -0400 (EDT) (envelope-from rsimmons@wlcg.com) X-Authentication-Warning: mail.wlcg.com: rsimmons owned process doing -bs Date: Wed, 8 Aug 2001 11:09:39 -0400 (EDT) From: Rob Simmons To: Subject: Re: =?X-UNKNOWN?B?UmU6IKHu0/LD+9eisuG/1bzkyerH67j3y83I/bj2tM68ttPyw/u7uQ==?= =?X-UNKNOWN?B?w+K30crU08Mh?= In-Reply-To: <20010807232521.V3910-100000@awww.jeah.net> Message-ID: <20010808110756.Q5701-100000@mail.wlcg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: by AMaViS perl-10 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: RIPEMD160 Please do not respond to spammers. All this gets is more spam sent to the list. Robert Simmons Systems Administrator http://www.wlcg.com/ On Tue, 7 Aug 2001, Chris Byrnes wrote: > Score. > > > Chris Byrnes, Managing Member > JEAH Communications, LLC > > On 9 Mar 2001, =CD=F8=C2=E7=CA=B1=B4=FA wrote: > > > > > > > =D7=F0=BE=B4=B5=C4=C5=F3=D3=D1=A3=AC=C4=FA=BA=C3=A3=A1 > > =B7=C7=B3=A3=B8=D0=D0=BB=C4=FA=B5=C4=E4=AF=C0=C0=A3=AC=C8=E7=B9=FB= =C4=FA=D5=FD=CE=AA=D1=B0=D5=D2=D2=BB=B8=F6=B8=FC=BA=C3=B5=C4ISP=B6=F8=B7=B3= =C4=D5=A3=AC=C4=C7=C3=B4=CE=D2=C3=C7=CD=F8=C2=E7=CA=B1=B4=FAhttp://www.now.= net.cn=CE=AA=C4=FA=CC=E1=B9=A9=C1=CB=D7=EE=BC=D1=B5=C4=D1=A1=D4=F1=A3=A1 > > > > =A1=EE =D3=F2=C3=FB=D7=A2=B2=E1 > > =D7=A2=B2=E1=D3=F2=C3=FB=D4=F9=CB=CD3=B8=F6=B4=CE=BC=B6=D3=F2=C3=FB(=B4= =F8VDNS)=A3=A1 =CD=AC=CA=B1=C9=EA=C7=EB=BF=D5=BC=E4=D4=D9=D4=F9=CB=CD3=B8= =F6=B4=CE=BC=B6=D3=F2=C3=FB=A3=A1 > > > > =A1=EE=D0=E9=C4=E2=D6=F7=BB=FA > > =D2=BB =CC=D8=B6=E0=D3=C5=BB=DD > > =B7=B2=D4=DA8.1=B5=BD9.1=D7=A2=B2=E1=D3=F2=C3=FB=CD=AC=CA=B1=C9=EA=C7= =EB=BF=D5=BC=E4=CB=CD6=B8=F6=B4=CE=BC=B6=D3=F2=C3=FB=A3=A1=B5=C8=D3=DA=D2= =BB=B8=F6=D3=F2=C3=FB=BE=CD=C4=DC=CD=AC=CA=B1=BD=A86=B8=F6=CD=F8=D5=BE=A3= =A1=CD=AC=CA=B1=BC=D3=CB=CD15=B8=F6=C9=CC=D3=C3=D3=CA=BC=FE=D5=CB=BA=C5=A3= =A1 > > > > =B6=FE =B3=AC=B5=CD=CC=D8=BC=DB > > 280=D4=AA=A3=A1=C4=FA=BF=C9=D2=D4=C1=A2=BF=CC=D3=B5=D3=D0=CE=C8=B6=A8= =B6=F8=BF=EC=CB=D9=B5=C4100M=D0=E9=C4=E2=D6=F7=BB=FA=BF=D5=BC=E4!=BB=B9=D3= =CC=D4=A5=CA=B2=C3=B4=C4=D8=A3=AC=B8=CF=BF=EC=D0=D0=B6=AF=B0=C9=A3=A1 > > > > =C8=FD =B3=B9=B5=D7=BD=E2=B7=C5 > > =CF=D6=D4=DA=CC=EC=BB=A5=BF=C6=BC=BC=B5=C4ASP=BA=CDACCESS=CA=FD=BE=DD= =BF=E2=C8=AB=C3=E6=BF=AA=B7=C5=A3=AC=D6=BB=D0=E8100=D4=AA=BE=CD=C8=C3=C4=FA= =B5=C4=CD=F8=D5=BE=D3=B5=D3=D0=CA=FD=BE=DD=BF=E2=A1=A3 > > =B2=A2=D3=D0=CC=E1=B9=A9CGI PERL PHP JSP =B5=C8=D2=BB=CC=E5=B8=DF=BC=B6= =BF=D5=BC=E4.=CB=F9=D3=D0=BF=D5=BC=E4=CA=B5=CA=B1=BF=AA=CD=A8=C3=E2=B7=D1= =CA=D4=D3=C315=CC=EC! > > > > > > =A1=EE=A1=EE"=BB=F0=BA=EC=CF=C4=C8=D5=A1=B1=D6=F7=BB=FA=CD=D0=B9=DC=D3= =C5=BB=DD=EC=AB=B7=E7=C8=AB=C3=E6=B5=C7=C2=BD=A3=AC=C7=BF=B4=F3=A1=A2=B8=DF= =B1=EA=D7=BC=B5=C4=B5=E7=D0=C5=BC=B6=CA=FD=BE=DD=D6=D0=D0=C4=BB=FA=B7=BF=A3= =AC=B8=DF=B0=B2=C8=AB=CC=D8=D0=D4=A1=A2=B8=DF=B7=FE=CE=F1=B1=EA=D7=BC=A1=A2= =D4=D9=BC=D3=C9=CF=BA=CF=C0=ED=B5=C4=BC=DB=B8=F1=A3=AC=CF=F2=B9=E3=B4=F3= =BF=CD=BB=A7=CC=E1=B9=A9=B8=DF=D0=D4=BC=DB=B1=C8=B5=C4=B7=FE=CE=F1=A1=A3=CF= =EA=BC=FBhttp://idc.now.net.cn > > =A1=EE=A1=EE=CD=AC=CA=B1=CE=D2=C3=C7=CF=F2=B9=E3=B4=F3=B8=F7=BD=EC=B3= =CF=D5=F7=B4=FA=C0=ED=A3=AC=C8=C8=B3=C0=D1=FB=C7=EB=C4=FA=BC=D3=C8=EB=CD=F8= =C2=E7=CA=B1=B4=FA=B5=C4=D2=B5=CE=F1=BA=CF=D7=F7=D5=F3=D3=AA=A3=AC=B9=B2=CD= =AC=B7=D6=CF=ED=CD=F8=C2=E7=CA=B1=B4=FA=B5=C4=C5=D3=B4=F3=BF=CD=BB=A7=D7=CA= =D4=B4=A1=A3=CF=EA=CF=B8=C7=EB=B7=C3=CE=CA=CE=D2=C3=C7=CD=F8=D5=BE=A1=A3 > > =BB=F2=D6=B1=BD=D3=C1=AA=CF=B5=CE=D2=C3=C7: > > =C7=F1=D0=A1=BD=E3 michelle@now.net.cn > > =C1=D6=CF=C8=C9=FA youko@now.net.cn=A1=A1=A1=A1=A1=A1 > > =B5=E7=BB=B0=A3=BA0756-2125583 22216376 > > =BC=BC=CA=F5=B2=BF=A3=BA > > sanry@now.net.cn youko@now.net.cn > > 0756--2216376 2139739 > > > > =BB=B6=D3=AD=D6=C2=D0=C5 Today's Network support@now.net.cn > > =BB=B6=D3=AD=C4=FA=B7=C3=CE=CA=CE=D2=C3=C7=B5=C4=CD=F8=D5=BE http://www= =2Enow.net.cn > > > > =CE=D2=C3=C7=D2=BB=D6=B1=D2=D4=D7=A8=D2=B5=A1=A2=D3=C5=D6=CA=A1=A2=C1= =EC=CF=C8=CE=AA=D7=DA=D6=BC=A3=AC=C8=C8=B3=CF=CE=AA=C4=FA=B7=FE=CE=F1=A3=A1 > > > > ... > > =D7=A2=A3=BAVDNS=BF=C9=CA=D3=BB=AF=D3=F2=C3=FB=B7=FE=CE=F1=C6=F7=A3=AC= =C4=DC=CA=B5=CF=D6=A3=D5=A3=D2=A3=CC=D7=AA=B7=A2=A1=A2=D6=F7=BB=FA=A3=C1=BC= =C7=C2=BC=A1=A2=A3=CD=A3=D8=D3=CA=BC=FE=BC=C7=C2=BC=A1=A2=A3=C9=A3=D0=D6=B8= =CF=F2=BF=D8=D6=C6=B5=C8=B2=D9=D7=F7,=B8=FC=BF=C9=D2=D4=CB=E6=D0=C4=CB=F9= =D3=FB=B5=D8=D4=F6=BC=D3=D7=D4=BC=BA=B5=C4=B4=CE=BC=B6=D3=F2=C3=FB=A3=AC=B0= =EF=D6=FA=C4=FA=BD=A8=C1=A2=B6=E0=B8=F6=CD=F8=D5=BE=A3=AC=C4=E3=BF=C9=D2=D4= =C8=C3=CB=FD=D6=B8=CF=F2=C8=CE=BA=CE=BF=D5=BC=E4=A1=A3 > > > > > > > > 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7cVY2v8Bofna59hYRAzi8AKCSYtM/y1xWWWqtEHD1NpUmVDddmQCfZvnI ifvBguXaAF7WNedH/tabvSc=3D =3DEMW7 -----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 Wed Aug 8 10:53:54 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.quidel.com (webmail.quidel.com [63.125.144.4]) by hub.freebsd.org (Postfix) with ESMTP id 8B2D237B421 for ; Wed, 8 Aug 2001 10:53:52 -0700 (PDT) (envelope-from et@quidel.com) Received: by mail.quidel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Aug 2001 10:53:23 -0700 Message-ID: <9D4A4E19244ED4119BE90050DAD5DD47BC55A3@mail.quidel.com> From: Etienne de Bruin To: "'freebsd-security@freebsd.org'" Subject: Racoon not compiling? Date: Wed, 8 Aug 2001 10:53:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Anyone notice that since last night the Racoon port is not compiling? pfkey_dump.c complains about sadb_x_sequence member not existing. eT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 13:56:48 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.system (pec-124-116.tnt8.m2.uunet.de [149.225.124.116]) by hub.freebsd.org (Postfix) with SMTP id B1F0137B40B for ; Wed, 8 Aug 2001 13:56:41 -0700 (PDT) (envelope-from mailings@analogon.com) Received: (qmail 23818 invoked by uid 1013); 8 Aug 2001 20:56:33 -0000 Received: from laptop.system (HELO laptop) (192.168.1.9) by daemon.system with SMTP; 8 Aug 2001 20:56:33 -0000 Message-ID: <002701c1204c$7386c520$0901a8c0@system> From: "Tom Beer" To: "Conrad Sabatier" , "Andre Goeree" Cc: References: Subject: Re: multiple port scans: tcp/8888 Date: Wed, 8 Aug 2001 22:55:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 Hi, the matter that the scans come from different addresses says, in first instant nothing. It could be a decoy'ed attack, where only one address is the "real" origin Greets TOm > > On 05-Aug-2001 Andre Goeree wrote: > > Hello -security, > > > > Attached is part of my ipfilter log. The file shows port scans coming > > in from 25 different IP addresses from all over the world (Europe, > > USA, Asia) to tcp/8888. Since I could not find any information about > > tcp/8888, any comments are appreciated. > > > > Ago. > > Port 8888 is used by the OpenNap (Napster clone) server. I'd say this is most > likely what people are looking for. > > -- > Conrad Sabatier > conrads@home.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 Aug 8 14:34:11 2001 Delivered-To: freebsd-security@freebsd.org Received: from devserver (unknown [64.132.176.66]) by hub.freebsd.org (Postfix) with ESMTP id 5D5DD37B61B for ; Wed, 8 Aug 2001 14:33:32 -0700 (PDT) (envelope-from support@tipclub.com) Received: from mail pickup service by devserver with Microsoft SMTPSVC; Wed, 8 Aug 2001 17:32:58 -0400 From: To: Subject: Welcome To Tipclub Date: Wed, 8 Aug 2001 17:32:58 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 08 Aug 2001 21:32:58.0813 (UTC) FILETIME=[B1A86ED0:01C12051] 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 have been referred to us to receive a Free Trial Membership to the first-ever online Tip Club. Tip Club is a local, online sales referral network whereas you share sales opportunities with members in your community - online!!!. Some people call them "breakfast clubs", "lead networks", or "referral clubs". We are the first to do it on the Internet! Membership is exclusive, once you sign up no other companies in your industry can join in your area. For more information, check us out at http://www.TipClub.com. If your interested, please reserve your industry opening now. Email us back with "Yes" on the subject line. Please include in your response your name, company name, industry and phone number. We only ask that if you join, you agree to be an active participant. If your not interested, just reply "No" in the subject line and and we will remove you from our referral list. Thank you! Sincerely, Tip Club Manager P.S. Refer five people to Tip Club and, if they join, receive a years membership free! Learn more about how tip clubs work: http://www.bni-sac.com/sacbee17jul.html http://centralohio.thesource.net/Files/9508162.html http://www.entrepreneur.com/Magazines/MA_SegArticle/0,1539,266943----1-,00 html http://austin.bcentral.com/austin/stories/1997/05/12/smallb4.html http://www.augustachronicle.com/stories/120699/abc_biztips.shtml http://columbus.bcentral.com/columbus/stories/1998/09/21/smallb1.html http://atlanta.bcentral.com/atlanta/stories/1999/07/19/smallb1.html http://columbus.bcentral.com/columbus/stories/2000/10/09/smallb1.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 15:22:38 2001 Delivered-To: freebsd-security@freebsd.org Received: from lariat.org (lariat.org [12.23.109.2]) by hub.freebsd.org (Postfix) with ESMTP id CE75737B403 for ; Wed, 8 Aug 2001 15:22:34 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.org [12.23.109.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id QAA17821 for ; Wed, 8 Aug 2001 16:22:28 -0600 (MDT) Message-Id: <4.3.2.7.2.20010808162112.045c0100@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Aug 2001 16:22:25 -0600 To: security@freebsd.org From: Brett Glass Subject: Switch from BSD to Win2K, and look what happens.... 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 According to an article at http://www.newsbytes.com/news/01/168837.html NewsBytes has confirmed that at least some of Hotmail's Win2K servers are infected with the Code Red worm and are attempting to infect others. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 15:24:42 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.chem.msu.ru (mail.chem.msu.ru [195.208.208.19]) by hub.freebsd.org (Postfix) with ESMTP id 3A4A137B406; Wed, 8 Aug 2001 15:24:34 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su ([158.250.32.97]) by mail.chem.msu.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NHPRWSXR; Thu, 9 Aug 2001 02:00:04 +0400 Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id f78M8W148715; Thu, 9 Aug 2001 02:08:32 +0400 (MSD) (envelope-from yar) Date: Thu, 9 Aug 2001 02:08:31 +0400 From: Yar Tikhiy To: hackers@freebsd.org, security@freebsd.org Subject: finger/fingerd & home directory permissions Message-ID: <20010809020831.B44660@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 Hello, [Once I've sent this to -audit, but then was pointed] [that it wasn't the right list for such a discussion] Currently, finger(1) reveals user information if the user has created the ``.nofinger'' file, but his home directory is unreadable for finger(1). In the case of local access, it's no problem, since anyone may read /etc/passwd directly. OTOH, letting remote folks peek at user information even if the user wants to hide himself is a bad thing. The issue I'd like to submit to discussion is what way to choose: a) Add a command-line option to finger(1) and fingerd(8) telling them not to reveal user information if the user's homedir is protected. b) Similar to a), but hide such users by default. c) Don't bother at all :-) Personally, I'd prefer b) since it's most secure and seems to break nothing. Do I overlook any complications? -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 15:35:19 2001 Delivered-To: freebsd-security@freebsd.org Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by hub.freebsd.org (Postfix) with ESMTP id 64F6537B401; Wed, 8 Aug 2001 15:35:04 -0700 (PDT) (envelope-from danderse@cs.utah.edu) Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by wrath.cs.utah.edu (8.11.1/8.11.1) with ESMTP id f78MZ3L10346; Wed, 8 Aug 2001 16:35:03 -0600 (MDT) From: David G Andersen Received: (from danderse@localhost) by faith.cs.utah.edu (8.11.1/8.11.1) id f78MZ2p10632; Wed, 8 Aug 2001 16:35:02 -0600 (MDT) Message-Id: <200108082235.f78MZ2p10632@faith.cs.utah.edu> Subject: Re: finger/fingerd & home directory permissions To: yar@FreeBSD.ORG (Yar Tikhiy) Date: Wed, 8 Aug 2001 16:35:02 -0600 (MDT) Cc: hackers@FreeBSD.ORG, security@FreeBSD.ORG In-Reply-To: <20010809020831.B44660@comp.chem.msu.su> from "Yar Tikhiy" at Aug 09, 2001 02:08:31 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 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 Lo and behold, Yar Tikhiy once said: > > In the case of local access, it's no problem, since anyone may read > /etc/passwd directly. OTOH, letting remote folks peek at user > information even if the user wants to hide himself is a bad thing. > > The issue I'd like to submit to discussion is what way to choose: > > a) Add a command-line option to finger(1) and fingerd(8) telling > them not to reveal user information if the user's homedir is > protected. > > b) Similar to a), but hide such users by default. > > c) Don't bother at all :-) > > Personally, I'd prefer b) since it's most secure and seems to break > nothing. Do I overlook any complications? Yes - it breaks the semantics of the existing fingerds that people are used to. It's a gratuitious change with little benefit that would simply confuse people who have a reasonable expectation about what the default behavior of 'finger' should be. Don't do (b). -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 15:40: 0 2001 Delivered-To: freebsd-security@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id CECCF37B414; Wed, 8 Aug 2001 15:39:57 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id AAFBF81D05; Wed, 8 Aug 2001 17:39:47 -0500 (CDT) Date: Wed, 8 Aug 2001 17:39:47 -0500 From: Alfred Perlstein To: David G Andersen Cc: Yar Tikhiy , security@FreeBSD.ORG Subject: Re: finger/fingerd & home directory permissions Message-ID: <20010808173947.I85642@elvis.mu.org> References: <20010809020831.B44660@comp.chem.msu.su> <200108082235.f78MZ2p10632@faith.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108082235.f78MZ2p10632@faith.cs.utah.edu>; from danderse@cs.utah.edu on Wed, Aug 08, 2001 at 04:35:02PM -0600 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 * David G Andersen [010808 17:36] wrote: > Lo and behold, Yar Tikhiy once said: > > > > In the case of local access, it's no problem, since anyone may read > > /etc/passwd directly. OTOH, letting remote folks peek at user > > information even if the user wants to hide himself is a bad thing. > > > > The issue I'd like to submit to discussion is what way to choose: > > > > a) Add a command-line option to finger(1) and fingerd(8) telling > > them not to reveal user information if the user's homedir is > > protected. > > > > b) Similar to a), but hide such users by default. > > > > c) Don't bother at all :-) > > > > Personally, I'd prefer b) since it's most secure and seems to break > > nothing. Do I overlook any complications? > > Yes - it breaks the semantics of the existing fingerds that > people are used to. It's a gratuitious change with little benefit > that would simply confuse people who have a reasonable expectation > about what the default behavior of 'finger' should be. Don't do (b). Actually, I'd prefer (b) if it was a command line option. ie, not the default. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 15:41:45 2001 Delivered-To: freebsd-security@freebsd.org Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by hub.freebsd.org (Postfix) with ESMTP id 2F7CC37B41C; Wed, 8 Aug 2001 15:41:40 -0700 (PDT) (envelope-from danderse@cs.utah.edu) Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by wrath.cs.utah.edu (8.11.1/8.11.1) with ESMTP id f78Mfc911115; Wed, 8 Aug 2001 16:41:38 -0600 (MDT) From: David G Andersen Received: (from danderse@localhost) by faith.cs.utah.edu (8.11.1/8.11.1) id f78Mfcr11144; Wed, 8 Aug 2001 16:41:38 -0600 (MDT) Message-Id: <200108082241.f78Mfcr11144@faith.cs.utah.edu> Subject: Re: finger/fingerd & home directory permissions To: bright@mu.org (Alfred Perlstein) Date: Wed, 8 Aug 2001 16:41:38 -0600 (MDT) Cc: danderse@cs.utah.edu (David G Andersen), yar@FreeBSD.ORG (Yar Tikhiy), security@FreeBSD.ORG In-Reply-To: <20010808173947.I85642@elvis.mu.org> from "Alfred Perlstein" at Aug 08, 2001 05:39:47 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 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 Lo and behold, Alfred Perlstein once said: > > > > a) Add a command-line option to finger(1) and fingerd(8) telling > > > them not to reveal user information if the user's homedir is > > > protected. > > > > > > b) Similar to a), but hide such users by default. > > > > > > c) Don't bother at all :-) > > > > > > Personally, I'd prefer b) since it's most secure and seems to break > > > nothing. Do I overlook any complications? > > > > Yes - it breaks the semantics of the existing fingerds that > > people are used to. It's a gratuitious change with little benefit > > that would simply confuse people who have a reasonable expectation > > about what the default behavior of 'finger' should be. Don't do (b). > > Actually, I'd prefer (b) if it was a command line option. > > ie, not the default. And this differs from suggestion (a) in exactly what way? :) -Dave To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 15:46:39 2001 Delivered-To: freebsd-security@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id BC35237B403; Wed, 8 Aug 2001 15:46:32 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id BEDC481D05; Wed, 8 Aug 2001 17:46:32 -0500 (CDT) Date: Wed, 8 Aug 2001 17:46:32 -0500 From: Alfred Perlstein To: David G Andersen Cc: Yar Tikhiy , security@FreeBSD.ORG Subject: Re: finger/fingerd & home directory permissions Message-ID: <20010808174632.J85642@elvis.mu.org> References: <20010808173947.I85642@elvis.mu.org> <200108082241.f78Mfcr11144@faith.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108082241.f78Mfcr11144@faith.cs.utah.edu>; from danderse@cs.utah.edu on Wed, Aug 08, 2001 at 04:41:38PM -0600 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 * David G Andersen [010808 17:41] wrote: > Lo and behold, Alfred Perlstein once said: > > > > > > a) Add a command-line option to finger(1) and fingerd(8) telling > > > > them not to reveal user information if the user's homedir is > > > > protected. > > > > > > > > b) Similar to a), but hide such users by default. > > > > > > > > c) Don't bother at all :-) > > > > > > > > Personally, I'd prefer b) since it's most secure and seems to break > > > > nothing. Do I overlook any complications? > > > > > > Yes - it breaks the semantics of the existing fingerds that > > > people are used to. It's a gratuitious change with little benefit > > > that would simply confuse people who have a reasonable expectation > > > about what the default behavior of 'finger' should be. Don't do (b). > > > > Actually, I'd prefer (b) if it was a command line option. > > > > ie, not the default. > > And this differs from suggestion (a) in exactly what way? :) Er, oops, damn caffine. :) -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 18:15:14 2001 Delivered-To: freebsd-security@freebsd.org Received: from ruminary.org (unknown [207.44.246.153]) by hub.freebsd.org (Postfix) with ESMTP id 6333B37B405 for ; Wed, 8 Aug 2001 18:14:57 -0700 (PDT) (envelope-from clark@ruminary.org) Received: by ruminary.org (Postfix, from userid 1000) id A203C1529E; Wed, 8 Aug 2001 18:14:56 -0700 (PDT) Date: Wed, 8 Aug 2001 18:14:56 -0700 From: clark shishido To: Brett Glass Cc: security@freebsd.org Subject: Re: Switch from BSD to Win2K, and look what happens.... Message-ID: <20010808181456.A4348@ruminary.org> References: <4.3.2.7.2.20010808162112.045c0100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010808162112.045c0100@localhost>; from brett@lariat.org on Wed, Aug 08, 2001 at 04:22:25PM -0600 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 Wed, Aug 08, 2001 at 04:22:25PM -0600, Brett Glass wrote: > According to an article at > > http://www.newsbytes.com/news/01/168837.html > > NewsBytes has confirmed that at least some of Hotmail's Win2K servers are > infected with the Code Red worm and are attempting to infect others. > I've confirmed this in my access logs at work. I'm lucky enough to be on 64.x.x.x Hotmail, a Hotmail test network, hmopal.com, hmdevlab.com not the entire domains, just certain machines in those domains. --clark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 18:22:35 2001 Delivered-To: freebsd-security@freebsd.org Received: from I-Sphere.COM (shell.i-sphere.com [209.249.146.70]) by hub.freebsd.org (Postfix) with ESMTP id 410C137B40A for ; Wed, 8 Aug 2001 18:22:18 -0700 (PDT) (envelope-from fasty@I-Sphere.COM) Received: (from fasty@localhost) by I-Sphere.COM (8.11.5/8.11.4) id f791Phf42535 for freebsd-security@freebsd.org; Wed, 8 Aug 2001 18:25:43 -0700 (PDT) (envelope-from fasty) Date: Wed, 8 Aug 2001 18:25:43 -0700 From: faSty To: freebsd-security@freebsd.org Subject: should I concerned? Message-ID: <20010808182543.A42490@i-sphere.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 Hi guys, I noticed the httpd's log (errors and access), someone tried expliot the security hole on apache webserver and I dont know what this is. my webserver apache version is Server version: Apache/1.3.19 (Unix) Server built: May 17 2001 20:14:06 Please help. thanks PS. logs below. -trev -- httpd-access.log -- 208.185.233.230 - - [08/Aug/2001:14:39:03 -0700] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 - "-" "-" 208.185.233.230 - - [08/Aug/2001:14:55:51 -0700] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 - "-" "-" 208.185.233.230 - - [08/Aug/2001:15:29:28 -0700] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 - "-" "-" 208.185.233.230 - - [08/Aug/2001:17:13:35 -0700] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 - "-" "-" -- end snip -- -- httpd-error.log -- [Wed Aug 8 14:39:03 2001] [error] [client 208.185.233.230] Invalid URI in request XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1 [Wed Aug 8 14:55:51 2001] [error] [client 208.185.233.230] Invalid URI in request XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1 [Wed Aug 8 15:29:28 2001] [error] [client 208.185.233.230] Invalid URI in request XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1 [Wed Aug 8 17:13:35 2001] [error] [client 208.185.233.230] Invalid URI in request XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1 [Wed Aug 8 18:09:29 2001] [notice] caught SIGTERM, shutting down -- i shut the webserver down in case till i find out what this is. -- snip end -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 18:32:10 2001 Delivered-To: freebsd-security@freebsd.org Received: from awww.jeah.net (awww.jeah.net [216.111.239.130]) by hub.freebsd.org (Postfix) with ESMTP id 854FD37B40C for ; Wed, 8 Aug 2001 18:31:53 -0700 (PDT) (envelope-from chris@jeah.net) Received: from localhost (chris@localhost) by awww.jeah.net (8.11.4/8.11.4) with ESMTP id f791WCi38858; Wed, 8 Aug 2001 20:32:12 -0500 (CDT) (envelope-from chris@jeah.net) Date: Wed, 8 Aug 2001 20:32:12 -0500 (CDT) From: Chris Byrnes To: faSty Cc: Subject: Re: should I concerned? In-Reply-To: <20010808182543.A42490@i-sphere.com> Message-ID: <20010808203136.W38823-100000@awww.jeah.net> 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 They were trying to exploit using the Code Red thing for Windows. It doesn't affect Apache, except it might make your Apache core because of the increased repeated hits. Don't worry bout it. Chris Byrnes, Managing Member JEAH Communications, LLC On Wed, 8 Aug 2001, faSty wrote: > Hi guys, > > I noticed the httpd's log (errors and access), someone tried expliot > the security hole on apache webserver and I dont know what this is. > > my webserver apache version is > > Server version: Apache/1.3.19 (Unix) > Server built: May 17 2001 20:14:06 > > > Please help. thanks > > PS. logs below. > > -trev > > -- httpd-access.log -- > 208.185.233.230 - - [08/Aug/2001:14:39:03 -0700] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 - "-" "-" > 208.185.233.230 - - [08/Aug/2001:14:55:51 -0700] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 - "-" "-" > 208.185.233.230 - - [08/Aug/2001:15:29:28 -0700] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 - "-" "-" > 208.185.233.230 - - [08/Aug/2001:17:13:35 -0700] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 - "-" "-" > > -- end snip -- > > -- httpd-error.log -- > [Wed Aug 8 14:39:03 2001] [error] [client 208.185.233.230] Invalid URI in request XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1 > [Wed Aug 8 14:55:51 2001] [error] [client 208.185.233.230] Invalid URI in request XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1 > [Wed Aug 8 15:29:28 2001] [error] [client 208.185.233.230] Invalid URI in request XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1 > [Wed Aug 8 17:13:35 2001] [error] [client 208.185.233.230] Invalid URI in request XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1 > [Wed Aug 8 18:09:29 2001] [notice] caught SIGTERM, shutting down > > -- i shut the webserver down in case till i find out what this is. > -- snip end -- > > 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 Aug 8 18:32:24 2001 Delivered-To: freebsd-security@freebsd.org Received: from intense.net (server.intense.net [199.217.236.1]) by hub.freebsd.org (Postfix) with ESMTP id 1A16837B401 for ; Wed, 8 Aug 2001 18:32:01 -0700 (PDT) (envelope-from bobber@intense.net) Received: from bob ([209.248.134.245]) by intense.net (8.8.8/8.8.8) with SMTP id UAA90616; Wed, 8 Aug 2001 20:31:59 -0500 (CDT) Message-ID: <007201c12073$270bd7e0$6c01a8c0@mpcsecurity.com> From: "Robert Herrold" To: "faSty" , References: <20010808182543.A42490@i-sphere.com> Subject: Re: should I concerned? Date: Wed, 8 Aug 2001 20:31:58 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 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 That's the code red (II) that's affecting only IIS (Windows NT Servers) ----- Original Message ----- From: "faSty" To: Sent: Wednesday, August 08, 2001 8:25 PM Subject: should I concerned? > Hi guys, > > I noticed the httpd's log (errors and access), someone tried expliot > the security hole on apache webserver and I dont know what this is. > > my webserver apache version is > > Server version: Apache/1.3.19 (Unix) > Server built: May 17 2001 20:14:06 > > > Please help. thanks > > PS. logs below. > > -trev > > -- httpd-access.log -- > 208.185.233.230 - - [08/Aug/2001:14:39:03 -0700] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858 %ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u53 1b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 - "-" "-" > 208.185.233.230 - - [08/Aug/2001:14:55:51 -0700] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858 %ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u53 1b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 - "-" "-" > 208.185.233.230 - - [08/Aug/2001:15:29:28 -0700] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858 %ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u53 1b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 - "-" "-" > 208.185.233.230 - - [08/Aug/2001:17:13:35 -0700] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858 %ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u53 1b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 - "-" "-" > > -- end snip -- > > -- httpd-error.log -- > [Wed Aug 8 14:39:03 2001] [error] [client 208.185.233.230] Invalid URI in request XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858% ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531 b%u53ff%u0078%u0000%u00=a HTTP/1.1 > [Wed Aug 8 14:55:51 2001] [error] [client 208.185.233.230] Invalid URI in request XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858% ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531 b%u53ff%u0078%u0000%u00=a HTTP/1.1 > [Wed Aug 8 15:29:28 2001] [error] [client 208.185.233.230] Invalid URI in request XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858% ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531 b%u53ff%u0078%u0000%u00=a HTTP/1.1 > [Wed Aug 8 17:13:35 2001] [error] [client 208.185.233.230] Invalid URI in request XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858% ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531 b%u53ff%u0078%u0000%u00=a HTTP/1.1 > [Wed Aug 8 18:09:29 2001] [notice] caught SIGTERM, shutting down > > -- i shut the webserver down in case till i find out what this is. > -- snip end -- > > 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 Aug 8 18:34:45 2001 Delivered-To: freebsd-security@freebsd.org Received: from aristotle.tamu.edu (Aristotle.tamu.edu [165.91.161.90]) by hub.freebsd.org (Postfix) with ESMTP id 828E637B411 for ; Wed, 8 Aug 2001 18:34:34 -0700 (PDT) (envelope-from rasmith@aristotle.tamu.edu) Received: from aristotle.tamu.edu (IDENT:rasmith@localhost [127.0.0.1]) by aristotle.tamu.edu (8.9.3/8.8.7) with ESMTP id UAA28759 for ; Wed, 8 Aug 2001 20:34:34 -0500 Message-Id: <200108090134.UAA28759@aristotle.tamu.edu> To: freebsd-security@FreeBSD.ORG Subject: Re: should I concerned? In-Reply-To: Your message of "Wed, 08 Aug 2001 18:25:43 PDT." <20010808182543.A42490@i-sphere.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Aug 2001 20:34:34 -0500 From: Robin Smith 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 >>>>> "faSty" == faSty writes: faSty> Hi guys, I noticed the httpd's log (errors and access), faSty> someone tried expliot the security hole on apache webserver faSty> and I dont know what this is. faSty> my webserver apache version is faSty> Server version: Apache/1.3.19 (Unix) Server built: May 17 faSty> 2001 20:14:06 faSty> [08/Aug/2001:14:39:03 -0700] faSty> "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a Relax: this is Code Red's signature (though the filler is X instead of N: is this Son of Code Red?). You're running apache, not IIS. Robin Smith To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 18:39:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from I-Sphere.COM (shell.i-sphere.com [209.249.146.70]) by hub.freebsd.org (Postfix) with ESMTP id 9EF4B37B405 for ; Wed, 8 Aug 2001 18:39:19 -0700 (PDT) (envelope-from fasty@I-Sphere.COM) Received: (from fasty@localhost) by I-Sphere.COM (8.11.5/8.11.4) id f791ge942949; Wed, 8 Aug 2001 18:42:40 -0700 (PDT) (envelope-from fasty) Date: Wed, 8 Aug 2001 18:42:40 -0700 From: faSty To: Robin Smith Cc: freebsd-security@freebsd.org Subject: Re: should I concerned? Message-ID: <20010808184240.A42930@i-sphere.com> References: <20010808182543.A42490@i-sphere.com> <200108090134.UAA28759@aristotle.tamu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108090134.UAA28759@aristotle.tamu.edu>; from rasmith@aristotle.tamu.edu on Wed, Aug 08, 2001 at 08:34:34PM -0500 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 allright, thanks -trev On Wed, Aug 08, 2001 at 08:34:34PM -0500, Robin Smith wrote: > >>>>> "faSty" == faSty writes: > > faSty> Hi guys, I noticed the httpd's log (errors and access), > faSty> someone tried expliot the security hole on apache webserver > faSty> and I dont know what this is. > > faSty> my webserver apache version is > > faSty> Server version: Apache/1.3.19 (Unix) Server built: May 17 > faSty> 2001 20:14:06 > > faSty> [08/Aug/2001:14:39:03 -0700] > faSty> "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a > > Relax: this is Code Red's signature (though the filler is X instead of > N: is this Son of Code Red?). You're running apache, not IIS. > > Robin Smith > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- "It is easier for a camel to pass through the eye of a needle if it is lightly greased." -- Kehlog Albran, "The Profit" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 23:29:40 2001 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6DC7437B401; Wed, 8 Aug 2001 23:29:35 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f796TYl09253; Thu, 9 Aug 2001 00:29:34 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f796TX127642; Thu, 9 Aug 2001 00:29:33 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108090629.f796TX127642@harmony.village.org> To: Yar Tikhiy Subject: Re: finger/fingerd & home directory permissions Cc: hackers@FreeBSD.ORG, security@FreeBSD.ORG In-reply-to: Your message of "Thu, 09 Aug 2001 02:08:31 +0400." <20010809020831.B44660@comp.chem.msu.su> References: <20010809020831.B44660@comp.chem.msu.su> Date: Thu, 09 Aug 2001 00:29:33 -0600 From: Warner Losh 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 In message <20010809020831.B44660@comp.chem.msu.su> Yar Tikhiy writes: : The issue I'd like to submit to discussion is what way to choose: : a) Add a command-line option to finger(1) and fingerd(8) telling : them not to reveal user information if the user's homedir is : protected. : b) Similar to a), but hide such users by default. : c) Don't bother at all :-) d) $HOME/.nofinger Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 23:30:23 2001 Delivered-To: freebsd-security@freebsd.org Received: from comnet.ca (comnet.ca [216.191.240.2]) by hub.freebsd.org (Postfix) with ESMTP id 0789737B406 for ; Wed, 8 Aug 2001 23:30:17 -0700 (PDT) (envelope-from webdesigns@comnet.ca) Received: from critter (64.39.176.9.comnet.ca [64.39.176.9]) by comnet.ca (8.11.3/8.11.3) with SMTP id f796U5S02114 for ; Thu, 9 Aug 2001 02:30:06 -0400 (EDT) Message-ID: <005f01c1209c$99ee68d0$bd7ba8c0@critter> From: "webdesigns COMNET" To: Subject: Routes Date: Thu, 9 Aug 2001 02:29:10 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01C1207B.123935D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 This is a multi-part message in MIME format. ------=_NextPart_000_005C_01C1207B.123935D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone, On my 4.3-STABLE box I have a new IP subnet implemented.=20 The box is connected to a router via a dmz host (internal ip).=20 The router is connected to the net with a different ip than the subnets. The only communication to the outside world is through my router's = internal ip. I have set the defaultrouter=3D"router's ip" in rc.conf and = I have access to the internet, except my ip address translates to the = external ip of the router. (Which I don't want) I would like all connections from my FreeBSD box to show on the internet = as one or any of my subnet ip's. Can someone help define a setup to get my subnet working. All and any advice is appreciated, Jason webdesigns@comnet.ca ------=_NextPart_000_005C_01C1207B.123935D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everyone,
 
On my 4.3-STABLE box I have a = new IP=20 subnet implemented.
The box is connected to a router via a = dmz host=20 (internal ip).
The router is connected to the net with = a different=20 ip than the subnets.
The only communication to the outside = world is=20 through my router's internal ip. I have set the = defaultrouter=3D"router's ip" in=20 rc.conf and I have access to the internet, except my ip address = translates to=20 the external ip of the router. (Which I don't want)
I would like all connections from my = FreeBSD box to=20 show on the internet as one or any of my subnet ip's.
Can someone help define a setup to get = my subnet=20 working.
 
All and any advice is = appreciated,
 
Jason
webdesigns@comnet.ca ------=_NextPart_000_005C_01C1207B.123935D0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Aug 8 23:55:41 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.chem.msu.ru (mail.chem.msu.ru [195.208.208.19]) by hub.freebsd.org (Postfix) with ESMTP id 66D6137B401; Wed, 8 Aug 2001 23:55:34 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su ([158.250.32.97]) by mail.chem.msu.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NHPRWS08; Thu, 9 Aug 2001 10:47:07 +0400 Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id f796t2c93954; Thu, 9 Aug 2001 10:55:02 +0400 (MSD) (envelope-from yar) Date: Thu, 9 Aug 2001 10:55:02 +0400 From: Yar Tikhiy To: Warner Losh Cc: hackers@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: finger/fingerd & home directory permissions Message-ID: <20010809105502.A92333@comp.chem.msu.su> References: <20010809020831.B44660@comp.chem.msu.su> <200108090629.f796TX127642@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108090629.f796TX127642@harmony.village.org>; from imp@harmony.village.org on Thu, Aug 09, 2001 at 12:29:33AM -0600 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 Thu, Aug 09, 2001 at 12:29:33AM -0600, Warner Losh wrote: > In message <20010809020831.B44660@comp.chem.msu.su> Yar Tikhiy writes: > : The issue I'd like to submit to discussion is what way to choose: > : a) Add a command-line option to finger(1) and fingerd(8) telling > : them not to reveal user information if the user's homedir is > : protected. > : b) Similar to a), but hide such users by default. > : c) Don't bother at all :-) > > d) $HOME/.nofinger It's just an equivalent of c) ;-) The top part of my message, which you skipped, I was speaking of the case when finger(1) couldn't access the home directory of a user and see the ".nofinger" file because of restrictive permission bits set on the directory. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 3:11:51 2001 Delivered-To: freebsd-security@freebsd.org Received: from pa169.kurdwanowa.sdi.tpnet.pl (pa169.kurdwanowa.sdi.tpnet.pl [213.77.148.169]) by hub.freebsd.org (Postfix) with ESMTP id A10DA37B403 for ; Thu, 9 Aug 2001 03:10:41 -0700 (PDT) (envelope-from kzaraska@student.uci.agh.edu.pl) Received: by pa169.kurdwanowa.sdi.tpnet.pl (Postfix, from userid 1001) id EF3241C87; Thu, 9 Aug 2001 12:04:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by pa169.kurdwanowa.sdi.tpnet.pl (Postfix) with ESMTP id A5642548B; Thu, 9 Aug 2001 12:04:44 +0200 (CEST) Date: Thu, 9 Aug 2001 12:04:44 +0200 (CEST) From: Krzysztof Zaraska X-Sender: kzaraska@lhotse.zaraska.dhs.org To: webdesigns COMNET Cc: freebsd-security@FreeBSD.ORG Subject: Re: Routes In-Reply-To: <005f01c1209c$99ee68d0$bd7ba8c0@critter> Message-ID: 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 On Thu, 9 Aug 2001, webdesigns COMNET wrote: > Hi everyone, > > On my 4.3-STABLE box I have a new IP subnet implemented. The box is > connected to a router via a dmz host (internal ip). The router is > connected to the net with a different ip than the subnets. The only > communication to the outside world is through my router's internal ip. > I have set the defaultrouter="router's ip" in rc.conf and I have > access to the internet, except my ip address translates to the > external ip of the router. (Which I don't want) I would like all > connections from my FreeBSD box to show on the internet as one or any > of my subnet ip's. Can someone help define a setup to get my subnet > working. Address translation is usually done by routers, thus it seems to me that this is the issue of router configuration. Unless you machine uses private IPs (that is one with subnet number of 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16) router may be reconfigured to stop translating your IP(s). This may however be a serious conflict with local security policy at your site, since internal addresses are usually hidden for some reason. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 3:25:48 2001 Delivered-To: freebsd-security@freebsd.org Received: from internethelp.ru (wh.internethelp.ru [212.113.112.145]) by hub.freebsd.org (Postfix) with ESMTP id 98C0A37B401 for ; Thu, 9 Aug 2001 03:25:43 -0700 (PDT) (envelope-from nkritsky@internethelp.ru) Received: from IBMKA (ibmka.internethelp.ru. [192.168.0.6]) by internethelp.ru (8.9.3/8.9.3) with ESMTP id OAA10580; Thu, 9 Aug 2001 14:25:22 +0400 (MSD) Date: Thu, 9 Aug 2001 14:25:23 +0400 From: "Nickolay A.Kritsky" X-Mailer: The Bat! (v1.49) Personal Reply-To: "Nickolay A.Kritsky" X-Priority: 3 (Normal) Message-ID: <7690233759.20010809142523@internethelp.ru> To: Robin Smith Cc: freebsd-security@FreeBSD.ORG Subject: Re[2]: should I concerned? In-reply-To: <200108090134.UAA28759@aristotle.tamu.edu> References: <200108090134.UAA28759@aristotle.tamu.edu> Mime-Version: 1.0 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 Hello Robin, Thursday, August 09, 2001, 5:34:34 AM, you wrote: >>>>>> "faSty" == faSty writes: RS> faSty> Hi guys, I noticed the httpd's log (errors and access), RS> faSty> someone tried expliot the security hole on apache webserver RS> faSty> and I dont know what this is. RS> faSty> my webserver apache version is RS> faSty> Server version: Apache/1.3.19 (Unix) Server built: May 17 RS> faSty> 2001 20:14:06 RS> faSty> [08/Aug/2001:14:39:03 -0700] RS> faSty> RS> "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a RS> Relax: this is Code Red's signature (though the filler is X instead of RS> N: is this Son of Code Red?). You're running apache, not IIS. I have thought that Code Red exploit string must begin with "/default.idq" Was I wrong? RS> Robin Smith RS> To Unsubscribe: send mail to majordomo@FreeBSD.org RS> with "unsubscribe freebsd-security" in the body of the message ;------------------------------------------- ; NKritsky ; SysAdmin InternetHelp.Ru ; http://www.internethelp.ru ; mailto:nkritsky@internethelp.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 3:35:35 2001 Delivered-To: freebsd-security@freebsd.org Received: from eve.framatome.fr (eve.framatome.fr [195.101.50.66]) by hub.freebsd.org (Postfix) with ESMTP id DE1AF37B405 for ; Thu, 9 Aug 2001 03:35:30 -0700 (PDT) (envelope-from ubc@paris.framatome.fr) Received: from localhost (ubc@localhost) by eve.framatome.fr (8.11.3/8.11.2) with ESMTP id f79AZLF04237; Thu, 9 Aug 2001 12:35:21 +0200 (CEST) (envelope-from ubc@eve.framatome.fr) Date: Thu, 9 Aug 2001 12:35:21 +0200 (CEST) From: Claude Buisson To: "Nickolay A.Kritsky" Cc: Robin Smith , Subject: Re[2]: should I concerned? In-Reply-To: <7690233759.20010809142523@internethelp.ru> Message-ID: <20010809123052.U4026-100000@eve.framatome.fr> 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 On Thu, 9 Aug 2001, Nickolay A.Kritsky wrote: > Hello Robin, > > Thursday, August 09, 2001, 5:34:34 AM, you wrote: > > >>>>>> "faSty" == faSty writes: > > RS> faSty> Hi guys, I noticed the httpd's log (errors and access), > RS> faSty> someone tried expliot the security hole on apache webserver > RS> faSty> and I dont know what this is. > > RS> faSty> my webserver apache version is > > RS> faSty> Server version: Apache/1.3.19 (Unix) Server built: May 17 > RS> faSty> 2001 20:14:06 > > RS> faSty> [08/Aug/2001:14:39:03 -0700] > RS> faSty> > RS> "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a > > RS> Relax: this is Code Red's signature (though the filler is X instead of > RS> N: is this Son of Code Red?). You're running apache, not IIS. > > I have thought that Code Red exploit string must begin with > "/default.idq" > Was I wrong? > I have seen a few of these starting from August 6, amidst a flow of "standard" GET /default.ida?NNNNNNNN... and GET /default.ida?XXXXXXX... Is Code Red II bugged ? > RS> Robin Smith > > RS> To Unsubscribe: send mail to majordomo@FreeBSD.org > RS> with "unsubscribe freebsd-security" in the body of the message > > > > > ;------------------------------------------- > ; NKritsky > ; SysAdmin InternetHelp.Ru > ; http://www.internethelp.ru > ; mailto:nkritsky@internethelp.ru > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Claude Buisson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 4:25:30 2001 Delivered-To: freebsd-security@freebsd.org Received: from aristotle.tamu.edu (Aristotle.tamu.edu [165.91.161.90]) by hub.freebsd.org (Postfix) with ESMTP id 8DB0937B403 for ; Thu, 9 Aug 2001 04:25:27 -0700 (PDT) (envelope-from rasmith@aristotle.tamu.edu) Received: from aristotle.tamu.edu (IDENT:rasmith@localhost [127.0.0.1]) by aristotle.tamu.edu (8.9.3/8.8.7) with ESMTP id GAA29210; Thu, 9 Aug 2001 06:25:25 -0500 Message-Id: <200108091125.GAA29210@aristotle.tamu.edu> To: freebsd-security@FreeBSD.ORG Cc: "Nickolay A.Kritsky" Subject: Re: Re[2]: should I concerned? In-Reply-To: Message from Claude Buisson of "Thu, 09 Aug 2001 12:35:21 +0200." <20010809123052.U4026-100000@eve.framatome.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Thu, 09 Aug 2001 06:25:25 -0500 From: Robin Smith 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 >>>>> "Claude" == Claude Buisson writes: Claude> I have seen a few of these starting from August 6, amidst Claude> a flow of "standard" GET /default.ida?NNNNNNNN... and GET Claude> /default.ida?XXXXXXX... Is Code Red II bugged ? My httpd access log is full of "GET /default/ida?XXX....", which is evidently the Code Red II signature; haven't seen very many Code Red I hits in the last few days (but Code Red II seems to hit us with much greaterfrequency). The "NNN.." and "XXX..." strings are just filler to overflow a buffer; the payload (and the real signature of the worm) is the bit of code at the end, which is object code encoded in hex ("%u" and four digits). Compare these and you'll see they are the same. But it's so much easier to type "grep NNNN /var/log/..." :=) Robin Smith To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 4:37:20 2001 Delivered-To: freebsd-security@freebsd.org Received: from eve.framatome.fr (eve.framatome.fr [195.101.50.66]) by hub.freebsd.org (Postfix) with ESMTP id 01C2637B401 for ; Thu, 9 Aug 2001 04:37:17 -0700 (PDT) (envelope-from ubc@paris.framatome.fr) Received: from localhost (ubc@localhost) by eve.framatome.fr (8.11.3/8.11.2) with ESMTP id f79BbEI04383; Thu, 9 Aug 2001 13:37:14 +0200 (CEST) (envelope-from ubc@eve.framatome.fr) Date: Thu, 9 Aug 2001 13:37:13 +0200 (CEST) From: Claude Buisson To: Robin Smith Cc: , "Nickolay A.Kritsky" Subject: Re: Re[2]: should I concerned? In-Reply-To: <200108091125.GAA29210@aristotle.tamu.edu> Message-ID: <20010809133535.I4371-100000@eve.framatome.fr> 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 On Thu, 9 Aug 2001, Robin Smith wrote: > > >>>>> "Claude" == Claude Buisson writes: > > > Claude> I have seen a few of these starting from August 6, amidst > Claude> a flow of "standard" GET /default.ida?NNNNNNNN... and GET > Claude> /default.ida?XXXXXXX... Is Code Red II bugged ? > > My httpd access log is full of "GET /default/ida?XXX....", which is > evidently the Code Red II signature; haven't seen very many Code Red I > hits in the last few days (but Code Red II seems to hit us with much > greaterfrequency). > > The "NNN.." and "XXX..." strings are just filler to overflow a buffer; > the payload (and the real signature of the worm) is the bit of code at > the end, which is object code encoded in hex ("%u" and four digits). > Compare these and you'll see they are the same. But it's so much easier > to type "grep NNNN /var/log/..." :=) This is already well known, the question is: why the "GET /default.ida?" is missing is some attempts ? > > Robin Smith > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Claude Buisson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 4:54:51 2001 Delivered-To: freebsd-security@freebsd.org Received: from peitho.fxp.org (peitho.fxp.org [209.26.95.40]) by hub.freebsd.org (Postfix) with ESMTP id BF4F337B401 for ; Thu, 9 Aug 2001 04:54:39 -0700 (PDT) (envelope-from cdf.lists@fxp.org) Received: by peitho.fxp.org (Postfix, from userid 1501) id BEB2E1360E; Thu, 9 Aug 2001 07:54:38 -0400 (EDT) Date: Thu, 9 Aug 2001 07:54:38 -0400 From: Chris Faulhaber To: Claude Buisson Cc: Robin Smith , freebsd-security@FreeBSD.ORG, "Nickolay A.Kritsky" Subject: Re: Re[2]: should I concerned? Message-ID: <20010809075438.A17562@peitho.fxp.org> Mail-Followup-To: Chris Faulhaber , Claude Buisson , Robin Smith , freebsd-security@FreeBSD.ORG, "Nickolay A.Kritsky" References: <200108091125.GAA29210@aristotle.tamu.edu> <20010809133535.I4371-100000@eve.framatome.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <20010809133535.I4371-100000@eve.framatome.fr> User-Agent: Mutt/1.3.20i 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 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 09, 2001 at 01:37:13PM +0200, Claude Buisson wrote: > On Thu, 9 Aug 2001, Robin Smith wrote: > > > > >>>>> "Claude" =3D=3D Claude Buisson writes: > > > > > > Claude> I have seen a few of these starting from August 6, amidst > > Claude> a flow of "standard" GET /default.ida?NNNNNNNN... and GET > > Claude> /default.ida?XXXXXXX... Is Code Red II bugged ? > > > > My httpd access log is full of "GET /default/ida?XXX....", which is > > evidently the Code Red II signature; haven't seen very many Code Red I > > hits in the last few days (but Code Red II seems to hit us with much > > greaterfrequency). > > > > The "NNN.." and "XXX..." strings are just filler to overflow a buffer; > > the payload (and the real signature of the worm) is the bit of code at > > the end, which is object code encoded in hex ("%u" and four digits). > > Compare these and you'll see they are the same. But it's so much easier > > to type "grep NNNN /var/log/..." :=3D) >=20 > This is already well known, the question is: >=20 > why the "GET /default.ida?" is missing is some attempts ? >=20 You may want to review the incidents/vuln-dev archives at www.securityfocus.com where this has been discussed-to-death over the last few weeks. --=20 Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org -------------------------------------------------------- FreeBSD: The Power To Serve - http://www.FreeBSD.org --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: FreeBSD: The Power To Serve iEYEARECAAYFAjtyef4ACgkQObaG4P6BelA3IQCeIBgAYg2n0phGTBzHvey6UrPy XCkAoIlAQaaiiovkabiruiieu2phLidQ =BGMP -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 7:13:38 2001 Delivered-To: freebsd-security@freebsd.org Received: from comnet.ca (comnet.ca [216.191.240.2]) by hub.freebsd.org (Postfix) with ESMTP id CA2DF37B406 for ; Thu, 9 Aug 2001 07:13:30 -0700 (PDT) (envelope-from webdesigns@comnet.ca) Received: from critter (64.39.176.9.comnet.ca [64.39.176.9]) by comnet.ca (8.11.3/8.11.3) with SMTP id f79E8mG10142; Thu, 9 Aug 2001 10:08:48 -0400 (EDT) Message-ID: <001501c120dc$ae732440$bd7ba8c0@critter> From: "webdesigns COMNET" To: "Krzysztof Zaraska" Cc: References: Subject: Re: Routes Date: Thu, 9 Aug 2001 10:07:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Thanks for your reply! ----- Original Message ----- From: "Krzysztof Zaraska" To: "webdesigns COMNET" Cc: Sent: Thursday, August 09, 2001 6:04 AM Subject: Re: Routes > On Thu, 9 Aug 2001, webdesigns COMNET wrote: > > > Hi everyone, > > > > On my 4.3-STABLE box I have a new IP subnet implemented. The box is > > connected to a router via a dmz host (internal ip). The router is > > connected to the net with a different ip than the subnets. The only > > communication to the outside world is through my router's internal ip. > > I have set the defaultrouter="router's ip" in rc.conf and I have > > access to the internet, except my ip address translates to the > > external ip of the router. (Which I don't want) I would like all > > connections from my FreeBSD box to show on the internet as one or any > > of my subnet ip's. Can someone help define a setup to get my subnet > > working. > > Address translation is usually done by routers, thus it seems to me that > this is the issue of router configuration. Unless you machine uses private > IPs (that is one with subnet number of 10.0.0.0/8, 172.16.0.0/12 or > 192.168.0.0/16) router may be reconfigured to stop translating your > IP(s). This may however be a serious conflict with local security policy > at your site, since internal addresses are usually hidden for some reason. > My router isn't capable of doing ip translation. It only provides 1 DMZ host, and/or nat specific ports to different lan ips. My machine is using ipfw, default router to the dmz host, 1 lan ip, and 32 public ips. The router only has 1 public address. I would like to share the public subnet across the 1 connection. I believe the router is my problem and should be omited, and a dual-homed setup implemented. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 16: 1:36 2001 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 4068337B401 for ; Thu, 9 Aug 2001 16:01:34 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f79N1VV21397; Thu, 9 Aug 2001 19:01:31 -0400 (EDT) (envelope-from wollman) Date: Thu, 9 Aug 2001 19:01:31 -0400 (EDT) From: Garrett Wollman Message-Id: <200108092301.f79N1VV21397@khavrinen.lcs.mit.edu> To: Brooks Davis Cc: security@freebsd.org Subject: Re: cvs commit: src/usr.sbin/wicontrol wicontrol.8 In-Reply-To: <20010809155123.A18472@Odin.AC.HMC.Edu> References: <200108092159.f79Lx8406626@freefall.freebsd.org> <20010809155123.A18472@Odin.AC.HMC.Edu> 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 < said: > WEP IS INSECURE. DO NOT TRUST IT TO PROVIDE SIGNIFICANT SECURITY. Let's keep in mind what WEP claims to be: Wired Equivalent Privacy. That is to say, the effort required to break WEP is comparable to the effort of plugging a wire into an outlet. It is not a security service. The mere existence of an (automatable) attack does not mean that WEP is irredeemably broken; for many applications, it is sufficient to protect against unintentional access. (We don't use WEP in our wireless network here, because to do so would defeat the purpose of the network. If I had a wireless network in my condo, on the other hand, you can be certain that I would be using it.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 17:44:25 2001 Delivered-To: freebsd-security@freebsd.org Received: from web12008.mail.yahoo.com (web12008.mail.yahoo.com [216.136.172.216]) by hub.freebsd.org (Postfix) with SMTP id 9624C37B401 for ; Thu, 9 Aug 2001 17:44:20 -0700 (PDT) (envelope-from bsd2000au@yahoo.com.au) Message-ID: <20010810004420.33780.qmail@web12008.mail.yahoo.com> Received: from [61.9.188.204] by web12008.mail.yahoo.com; Fri, 10 Aug 2001 10:44:20 EST Date: Fri, 10 Aug 2001 10:44:20 +1000 (EST) From: =?iso-8859-1?q?Keith=20Spencer?= To: fbsdsec MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 Hi all, I have been hacked/cracked...they put a backdoor and a BNC on my gateway router (damn) So...I am in the middle of an urgent anti-hacking rebuild. Should I build a separate preimeter firewall machine with only that on it...restrict/remove compilers etc (how do I do that?) and have the router/dns/web/wail server inside the perimeter. OR should I simply put IPFW on the router/dns/web/mail server? Any ideas guys? Tjhanks Keith _____________________________________________________________________________ _____________________________________________________________________________ http://shopping.yahoo.com.au - Father's Day Shopping - Find the perfect gift for your Dad for Father's Day To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 17:47:54 2001 Delivered-To: freebsd-security@freebsd.org Received: from web12004.mail.yahoo.com (web12004.mail.yahoo.com [216.136.172.212]) by hub.freebsd.org (Postfix) with SMTP id A45B037B403 for ; Thu, 9 Aug 2001 17:47:49 -0700 (PDT) (envelope-from bsd2000au@yahoo.com.au) Message-ID: <20010810004749.15817.qmail@web12004.mail.yahoo.com> Received: from [61.9.188.204] by web12004.mail.yahoo.com; Fri, 10 Aug 2001 10:47:49 EST Date: Fri, 10 Aug 2001 10:47:49 +1000 (EST) From: =?iso-8859-1?q?Keith=20Spencer?= Subject: Re: Separate firewall or not...OOPS no subject sorry! To: fbsdsec In-Reply-To: <20010810004420.33780.qmail@web12008.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 Sorry guys I forgot the subject line --- Keith Spencer wrote: > Hi all, > I have been hacked/cracked...they put a backdoor and > a > BNC on my gateway router (damn) > So...I am in the middle of an urgent anti-hacking > rebuild. > Should I build a separate preimeter firewall machine > with only that on it...restrict/remove compilers etc > (how do I do that?) and have the router/dns/web/wail > server inside the perimeter. > > OR > > should I simply put IPFW on the router/dns/web/mail > server? > Any ideas guys? > Tjhanks > Keith > > _____________________________________________________________________________ > > _____________________________________________________________________________ > http://shopping.yahoo.com.au - Father's Day Shopping > - Find the perfect gift for your Dad for Father's > Day > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of > the message _____________________________________________________________________________ http://shopping.yahoo.com.au - Father's Day Shopping - Find the perfect gift for your Dad for Father's Day To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 18:14:42 2001 Delivered-To: freebsd-security@freebsd.org Received: from gnjilux.srk.fer.hr (gnjilux.srk.fer.hr [161.53.70.141]) by hub.freebsd.org (Postfix) with ESMTP id 9142837B403 for ; Thu, 9 Aug 2001 18:14:39 -0700 (PDT) (envelope-from ike@gnjilux.srk.fer.hr) Received: from gnjilux.srk.fer.hr (ike@localhost [127.0.0.1]) by localhost (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id f7A1EU5J008475 for ; Fri, 10 Aug 2001 03:14:31 +0200 Received: (from ike@localhost) by gnjilux.srk.fer.hr (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) id f7A1EUEg008472 for freebsd-security@freebsd.org; Fri, 10 Aug 2001 03:14:30 +0200 From: Ivan Krstic Date: Fri, 10 Aug 2001 03:14:30 +0200 To: freebsd-security@freebsd.org Subject: Re: Separate firewall or not...OOPS no subject sorry! Message-ID: <20010810031430.S3889@gnjilux.cc.fer.hr> References: <20010810004420.33780.qmail@web12008.mail.yahoo.com> <20010810004749.15817.qmail@web12004.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010810004749.15817.qmail@web12004.mail.yahoo.com>; from bsd2000au@yahoo.com.au on Fri, Aug 10, 2001 at 10:47:49AM +1000 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 Fri, Aug 10, 2001 at 10:47:49AM +1000, Keith Spencer wrote: > Should I build a separate preimeter firewall machine > with only that on it...restrict/remove compilers etc > (how do I do that?) and have the router/dns/web/wail > server inside the perimeter. This would be the most desired solution, if you have the resources to spare for a separate firewall machine. If this machine would serve no other purpose beside being a firewall, just about any old box (PI) will do for SOHOs. My recommendations would be not to have ANY services running on this box at all (firewalled ssh if physical access is not available). In that sense, don't forget to turn off inetd completely, and if your firewall configuration does not change often, you might want to put the machine in securelevel 3 (sysctl kern.securelevel) so ipfw chains cannot be changed without a reboot. Obviously, it would be best if this machine had only one user account - yours. With this setup, disabling gcc is not too important, but you can still chown it to root.root and set its permissions to 700. Do, however, keep in mind that if somehow this machine gets compromised, attackers will have alternatives to using your gcc (using pre-compiled binaries, using lynx or wget to acquire gcc, etc.) I'm currently in the process of writing a brief locking-down-FreeBSD paper, and I'll be sure to post its address here once it's completed. Best regards, -- Ivan Krstic - ike " life is the road beneath my feet, love is the girl I wait to meet, and art is everything I create, rob me of any and I will hate, you, my God, my devil, my fate " To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 18:15:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns2.austclear.com.au (ns2.austclear.com.au [192.43.185.70]) by hub.freebsd.org (Postfix) with ESMTP id 2D5C237B406 for ; Thu, 9 Aug 2001 18:15:07 -0700 (PDT) (envelope-from ahl@austclear.com.au) Received: from tungsten.austclear.com.au (tungsten.austclear.com.au [192.168.166.65]) by ns2.austclear.com.au (8.11.2/8.11.3) with ESMTP id f7A1F5420696 for ; Fri, 10 Aug 2001 11:15:06 +1000 (EST) (envelope-from ahl@austclear.com.au) Received: from tungsten (tungsten [192.168.166.65]) by tungsten.austclear.com.au (8.9.3/8.9.3) with ESMTP id LAA20997; Fri, 10 Aug 2001 11:15:05 +1000 (EST) Message-Id: <200108100115.LAA20997@tungsten.austclear.com.au> X-Mailer: exmh version 2.1.1 10/15/1999 To: freebsd-security@freebsd.org Subject: distributed natd Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Aug 2001 11:15:04 +1000 From: Tony Landells 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 Hi all! I've been thinking about ways to improve the robustness of my firewall and I came up with the following idea, so I thought I'd run it past some other people for feedback. The idea is to run two (or more) firewalls in parallel in such a way that if one failed the other one would pick up the slack without users noticing. With our current firewall, we generally proxy connections, but for some things (mostly SSH) we just let it through ipfw, using natd to translate a "virtual" external address to the internal address of the target host. It occurred to me that if you could make a "distributed" natd, then you could actually get everyone to use virtual addresses for everything, and use dynamic routing to control which firewall handles the traffic. As far as I can see, the requirements for doing this are: a way to restrict the port numbers that natd will use so that each firewall will have a unique range a way for the natd processes on each firewall to tell each other when they set up or delete a translation a way for a starting natd process to obtain a state table from the natd processes on the other firewall(s) a way to tell each natd process what its "peers" are Obviously, this wouldn't work terribly well with stateful packet filtering... I haven't even begun to look at the code for natd, but can anyone see any fatal flaws in the concept? Tony -- Tony Landells Senior Network Engineer Ph: +61 3 9677 9319 Australian Clearing Services Pty Ltd Fax: +61 3 9677 9355 Level 4, Rialto North Tower 525 Collins Street Melbourne VIC 3000 Australia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 18:22: 4 2001 Delivered-To: freebsd-security@freebsd.org Received: from gnjilux.srk.fer.hr (gnjilux.srk.fer.hr [161.53.70.141]) by hub.freebsd.org (Postfix) with ESMTP id 7AFCA37B401 for ; Thu, 9 Aug 2001 18:22:01 -0700 (PDT) (envelope-from ike@gnjilux.srk.fer.hr) Received: from gnjilux.srk.fer.hr (ike@localhost [127.0.0.1]) by localhost (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id f7A1Lw5J008577 for ; Fri, 10 Aug 2001 03:21:58 +0200 Received: (from ike@localhost) by gnjilux.srk.fer.hr (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) id f7A1Lw0L008574 for freebsd-security@FreeBSD.ORG; Fri, 10 Aug 2001 03:21:58 +0200 From: Ivan Krstic Date: Fri, 10 Aug 2001 03:21:58 +0200 To: freebsd-security@FreeBSD.ORG Subject: Re: distributed natd Message-ID: <20010810032158.T3889@gnjilux.cc.fer.hr> References: <200108100115.LAA20997@tungsten.austclear.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <200108100115.LAA20997@tungsten.austclear.com.au>; from ahl@austclear.com.au on Fri, Aug 10, 2001 at 11:15:04AM +1000 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 Hi, On Fri, Aug 10, 2001 at 11:15:04AM +1000, Tony Landells wrote: > I've been thinking about ways to improve the robustness of my firewall > and I came up with the following idea, so I thought I'd run it past > some other people for feedback. I'm not sure I understood correctly - what are you aiming for? The performance increase due to two firewalls simultaneously processing traffic or the reduncancy of having one firewall take over if the other fails? If it's the latter, I believe there are simpler solutions than rewriting natd. -- Ivan Krstic - ike " life is the road beneath my feet, love is the girl I wait to meet, and art is everything I create, rob me of any and I will hate, you, my God, my devil, my fate " To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 19:25:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns2.austclear.com.au (ns2.austclear.com.au [192.43.185.70]) by hub.freebsd.org (Postfix) with ESMTP id 0497E37B405 for ; Thu, 9 Aug 2001 19:25:09 -0700 (PDT) (envelope-from ahl@austclear.com.au) Received: from tungsten.austclear.com.au (tungsten.austclear.com.au [192.168.166.65]) by ns2.austclear.com.au (8.11.2/8.11.3) with ESMTP id f7A2P4420991 for ; Fri, 10 Aug 2001 12:25:07 +1000 (EST) (envelope-from ahl@austclear.com.au) Received: from tungsten (tungsten [192.168.166.65]) by tungsten.austclear.com.au (8.9.3/8.9.3) with ESMTP id MAA23117; Fri, 10 Aug 2001 12:25:04 +1000 (EST) Message-Id: <200108100225.MAA23117@tungsten.austclear.com.au> X-Mailer: exmh version 2.1.1 10/15/1999 To: freebsd-security@FreeBSD.ORG Subject: Re: distributed natd In-Reply-To: Your message of "Fri, 10 Aug 2001 03:21:58 +0200." <20010810032158.T3889@gnjilux.cc.fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Aug 2001 12:25:04 +1000 From: Tony Landells 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 ike@gnjilux.srk.fer.hr said: > I'm not sure I understood correctly - what are you aiming for? The > performance increase due to two firewalls simultaneously processing > traffic or the reduncancy of having one firewall take over if the > other fails? > If it's the latter, I believe there are simpler solutions than > rewriting natd. Mostly the latter, with an additional (side benefit) of the former. We have several "long-term" connections for application services that go through our firewall(s). At the moment if one of the firewalls went down we'd have a major exercise to change DNS, restart services, and so on to switch everything across. If we were using "virtual" addresses then the switchover would be more or less transparent. However, we don't have a one-to-one mapping between internal addresses and external addresses, so there is a chance that the mapping one firewall would choose wouldn't be the same as that chosen by the second. Hence my suggestion. The side benefit is that I could then look at, for example, using dynamic routing to get equal cost paths through each box for load sharing when they're both up. Tony -- Tony Landells Senior Network Engineer Ph: +61 3 9677 9319 Australian Clearing Services Pty Ltd Fax: +61 3 9677 9355 Level 4, Rialto North Tower 525 Collins Street Melbourne VIC 3000 Australia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 19:27:44 2001 Delivered-To: freebsd-security@freebsd.org Received: from jdl.com (chrome.jdl.com [209.39.144.2]) by hub.freebsd.org (Postfix) with ESMTP id 8B39037B401 for ; Thu, 9 Aug 2001 19:27:39 -0700 (PDT) (envelope-from jdl@jdl.com) Received: from localhost ([127.0.0.1] helo=jdl.com) by jdl.com with esmtp (Exim 3.32 #1) id 15V26p-000ILM-00 for security@freebsd.org; Thu, 09 Aug 2001 21:33:11 -0500 To: security@freebsd.org Subject: IPFW Dynamic Rules Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Thu, 09 Aug 2001 21:33:10 -0500 From: Jon Loeliger Message-Id: 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 Hi Folks, The late night reconfiguring and firewall building progresses fairly nicely here these days, thanks to many here who have helped me. For those keeping score with my Sorry Saga, I've actually managed to replace the compromised disk, rebuild a new one, rebuild three new FreeBSD 4.3 released machines, turn one into an IPFW firewall gateway, and keep my day job. *phew* So, I have a rudimentary set of IPFW rules in place, loosly based off of the stock 4.3 "/etc/rc.firewall simple" set. Naturally, there is an endless amount of tinkering to do now, and I have some questions! For starters, what is a "dynamic rule", really? I mean, I've read the man page, and I've poked some web pages, and I _think_ I know, but I'm still unclear on a point or two. The man page says, about the keep-state flag, which is used to introduce new dynamic rules: keep-state [method] Upon a match, the firewall will create a dynamic rule, whose default behaviour is to matching bidirectional traffic between source and destination IP/port using the same protocol. The rule has a limited lifetime (con- trolled by a set of sysctl(8) variables), and the life- time is refreshed every time a matching packet is found. So if the dynamic rule has the same behaviour as the origination rule on the same port with the same protocol, why can't packets simply continue to be matched against that original base rule? Why does the dynamic rule even need to come into existence? How many dynamic rules do you need to allow for, roughly, based on some simple system paramters? Pure heuristic and guess work here? Markov chain arrival rate rule decay rate blah blah tune it blah blah? I filled the default 256 readily, and bumped it to 1024 on a whim. So I think I may be doing something vaguely Not Quite Right with some "keep-state" rules too. I think I got to this NQR state due to some early wrong rule tinkering. To be concrete: I first made the mistake of being too uni-directional and had a rule like this, intending to mean "anything that is established between the Big Bad Outside and my net, let it through." 00800 allow tcp from any to MY_REAL_NET/MASK established and this one intended to allow access to a web server: 01200 allow tcp from any to 209.39.144.0/27 80 setup I of course couldn't get this to work at all. The way I fixed it and made it work was to do change the "setup" rule to add the "keep-state" flag as well: 01200 allow tcp from any to MY_REAL_NET/MASK 80 setup keep-state What this did was introduce a dynamic rule for every connection to my web server. (Ugh.) What _wasn't_ happening was the _bidirectional_ treatment required from the 800 rule, right? The 800 rule is being used once in-bound and once out-bound, right? and with the rule written as above, the out-flow packets were being dropped on the floor and I _wasn't_ able to maintain the connections that the 1200 rule was correctly establishing, right? My stop-gap was to frob the keep-state onto that 1200 rule and now the dynamic rule was correctly getting me bidirectional traffic. All at the cost of introducing another unnneeded rule, right? To make matters worse, I was seeing this effect on my mail, ssh, http, https and DNS. Ugh, right? Wrong, right? What I need to do is change the 800 rule to be: 00800 allow tcp from any to any established and take the keep-state off the 1200 rule again: 01200 allow tcp from any to MY_REAL_NET/MASK 80 setup Did I even come close here? Now, other questions. Easy ones. What do you set the log-limit to? Like, I exceed 30 hits on my main deny rule in an hour easily. I've got script kiddies who are scanning up and down my address and port space. A lot. Piss me off. Damn good thing I've got a firewall going, I see now. What do people do to the log entries? I mean, is there some script out there that paws through /var/log/security and summarizes who was hitting on you and a histogram of ports probed? Do most people reset the counters once a day and leave it at that? Converted, jdl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 19:29:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from w2xo.pgh.pa.us (18.gibs5.xdsl.nauticom.net [209.195.184.19]) by hub.freebsd.org (Postfix) with ESMTP id 22BFF37B406 for ; Thu, 9 Aug 2001 19:29:09 -0700 (PDT) (envelope-from durham@w2xo.pgh.pa.us) Received: from localhost (localhost [127.0.0.1]) by w2xo.pgh.pa.us (8.11.3/8.11.3) with ESMTP id f7A2bRm90426; Thu, 9 Aug 2001 22:37:28 -0400 (EDT) (envelope-from durham@w2xo.pgh.pa.us) Date: Thu, 9 Aug 2001 22:37:27 -0400 (EDT) From: Jim Durham To: Josef Karthauser Cc: Nuno Teixeira , freebsd-security@FreeBSD.ORG Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... In-Reply-To: <20010801235514.D1443@tao.org.uk> Message-ID: 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 On Wed, 1 Aug 2001, Josef Karthauser wrote: > On Wed, Aug 01, 2001 at 10:01:41PM +0100, Nuno Teixeira wrote: > > > My question is: what is the real danger of doing `installworld` in > > multiuser mode? I have doing a lot of tests in other machines tracking > > STABLE and I have no problems so far. > > I've _always_ done installworld in multiuser on many servers. That > doesn't mean that it's the safest way, but it was safe enough for me. > > Joe > Well, I got talked into trying this and it panic'd the running kernel, so I won't do it that way again! I know lots of folks have gotten away with this, but it seems to be Russian Roulette.. I now have a "boot.config" file with "-h" in it and a null modem cable to my portmaster. I reboot into single-user, telnet into the portmaster and get on the serial port. Works very well. You could also cross-connect serial ports from another server. -Jim Durham To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 19:41:26 2001 Delivered-To: freebsd-security@freebsd.org Received: from cloud9.pain.net (cloud9.pain.net [209.58.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 3C20837B403 for ; Thu, 9 Aug 2001 19:41:20 -0700 (PDT) (envelope-from erb@cloud9.pain.net) Received: from localhost (erb@localhost) by cloud9.pain.net (8.11.5/8.11.1) with ESMTP id f7A2eZt33996; Thu, 9 Aug 2001 22:40:35 -0400 (EDT) (envelope-from erb@cloud9.pain.net) Date: Thu, 9 Aug 2001 22:40:35 -0400 (EDT) From: erb To: Jim Durham Cc: Josef Karthauser , Nuno Teixeira , Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... In-Reply-To: Message-ID: 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 Hmm.. I only update the 'world' if I am changing something that requires it, other then that I use a crontab entry that looks similiar to this.. #run cvsup every week at 2:30 AM (Friday) + compile/install new kernel 30 2 * * 5 root newkernel and the newkernel script is as follows.. #!/bin/sh # New kernel script, will cvsup, configure, compiling and install # new kernel from source. -erb # PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin export PATH cvsup -g -L 2 /etc/supfile >/var/tmp/cvsup.out 2>&1 cd /usr/src/sys/i386/conf config CLOUD9 >/var/tmp/config.out 2>&1 cd /usr/src make update >/var/tmp/update.out 2>&1 #make buildworld >/var/tmp/buildworld.out 2>&1 #make installworld >/var/tmp/installworld.out 2>&1 make buildkernel KERNCONF=CLOUD9 >/var/tmp/buildkernel.out 2>&1 make installkernel KERNCONF=CLOUD9 >/var/tmp/installkernel.out 2>&1 echo "CVSUp, & Kernel compile/install completed. For more information referr to /var/tmp and browse through the .out files." | mail -s "cvsup & kernel compile completed" sysadmin@cloud9.pain.net seems to do the trick just fine, could anyone let me know if this is a bad idea? On Thu, 9 Aug 2001, Jim Durham wrote: > On Wed, 1 Aug 2001, Josef Karthauser wrote: > > > On Wed, Aug 01, 2001 at 10:01:41PM +0100, Nuno Teixeira wrote: > > > > > My question is: what is the real danger of doing `installworld` in > > > multiuser mode? I have doing a lot of tests in other machines tracking > > > STABLE and I have no problems so far. > > > > I've _always_ done installworld in multiuser on many servers. That > > doesn't mean that it's the safest way, but it was safe enough for me. > > > > Joe > > > > Well, I got talked into trying this and it panic'd the running > kernel, so I won't do it that way again! I know lots of folks have > gotten away with this, but it seems to be Russian Roulette.. > > I now have a "boot.config" file with "-h" in it and a null modem > cable to my portmaster. I reboot into single-user, telnet into > the portmaster and get on the serial port. Works very well. > You could also cross-connect serial ports from another server. > > -Jim Durham > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 20:29: 9 2001 Delivered-To: freebsd-security@freebsd.org Received: from db.nexgen.com (db.nexgen.com [66.92.98.149]) by hub.freebsd.org (Postfix) with SMTP id 03CAE37B401 for ; Thu, 9 Aug 2001 20:29:05 -0700 (PDT) (envelope-from ml@db.nexgen.com) Received: (qmail 4051 invoked from network); 10 Aug 2001 03:28:33 -0000 Received: from localhost.nexgen.com (HELO alexus) (root@127.0.0.1) by localhost.nexgen.com with SMTP; 10 Aug 2001 03:28:33 -0000 Message-ID: <002501c1214d$07a5cf70$0100a8c0@alexus> From: "alexus" To: "erb" , "Jim Durham" Cc: "Josef Karthauser" , "Nuno Teixeira" , References: Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... Date: Thu, 9 Aug 2001 23:32:05 -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.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 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'm more or less newbie here can you explain me why would you ever want to do cvsup+rebuild kernel every friday? what's wrong with your old kernel? ----- Original Message ----- From: "erb" To: "Jim Durham" Cc: "Josef Karthauser" ; "Nuno Teixeira" ; Sent: Thursday, August 09, 2001 10:40 PM Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... > Hmm.. I only update the 'world' if I am changing something that requires > it, other then that I use a crontab entry that looks similiar to this.. > > #run cvsup every week at 2:30 AM (Friday) + compile/install new kernel > 30 2 * * 5 root newkernel > > and the newkernel script is as follows.. > > #!/bin/sh > # New kernel script, will cvsup, configure, compiling and install > # new kernel from source. -erb > # > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin > export PATH > cvsup -g -L 2 /etc/supfile >/var/tmp/cvsup.out 2>&1 > cd /usr/src/sys/i386/conf > config CLOUD9 >/var/tmp/config.out 2>&1 > cd /usr/src > make update >/var/tmp/update.out 2>&1 > #make buildworld >/var/tmp/buildworld.out 2>&1 > #make installworld >/var/tmp/installworld.out 2>&1 > make buildkernel KERNCONF=CLOUD9 >/var/tmp/buildkernel.out 2>&1 > make installkernel KERNCONF=CLOUD9 >/var/tmp/installkernel.out 2>&1 > echo "CVSUp, & Kernel compile/install completed. For more information > referr to /var/tmp and browse through the .out files." | mail -s "cvsup & kernel compile completed" sysadmin@cloud9.pain.net > > seems to do the trick just fine, could anyone let me know if this is a bad > idea? > > On Thu, 9 Aug 2001, Jim Durham wrote: > > > On Wed, 1 Aug 2001, Josef Karthauser wrote: > > > > > On Wed, Aug 01, 2001 at 10:01:41PM +0100, Nuno Teixeira wrote: > > > > > > > My question is: what is the real danger of doing `installworld` in > > > > multiuser mode? I have doing a lot of tests in other machines tracking > > > > STABLE and I have no problems so far. > > > > > > I've _always_ done installworld in multiuser on many servers. That > > > doesn't mean that it's the safest way, but it was safe enough for me. > > > > > > Joe > > > > > > > Well, I got talked into trying this and it panic'd the running > > kernel, so I won't do it that way again! I know lots of folks have > > gotten away with this, but it seems to be Russian Roulette.. > > > > I now have a "boot.config" file with "-h" in it and a null modem > > cable to my portmaster. I reboot into single-user, telnet into > > the portmaster and get on the serial port. Works very well. > > You could also cross-connect serial ports from another server. > > > > -Jim Durham > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Aug 9 21:12:29 2001 Delivered-To: freebsd-security@freebsd.org Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by hub.freebsd.org (Postfix) with ESMTP id 5D18937B407 for ; Thu, 9 Aug 2001 21:12:14 -0700 (PDT) (envelope-from tom@gottheil.com) Received: from humbaba (nelazul@h0020182d540a.ne.mediaone.net [24.128.52.27]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f7A4C7x13459; Fri, 10 Aug 2001 00:12:07 -0400 (EDT) Message-ID: <000a01c12152$a32b66d0$0200a8c0@humbaba> From: "Tom Gottheil" To: "alexus" Cc: References: <002501c1214d$07a5cf70$0100a8c0@alexus> Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... Date: Fri, 10 Aug 2001 00:12:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Well, nobody has to, it's just more fun that way... Mostly you can get bug fixes and such, but as has been repeatedly discussed (and then a bit more), -STABLE is not necessarily "stable". (No, I'm not trying to start anything again...) Mostly people who cvsup that frequenly are developers or at least interested in the cutting edge (then there's current...) ----- Original Message ----- From: "alexus" To: "erb" ; "Jim Durham" Cc: "Josef Karthauser" ; "Nuno Teixeira" ; Sent: Thursday, August 09, 2001 11:32 PM Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... > i'm more or less newbie here > > can you explain me why would you ever want to > > do cvsup+rebuild kernel every friday? what's wrong with your old kernel? > > ----- Original Message ----- > From: "erb" > To: "Jim Durham" > Cc: "Josef Karthauser" ; "Nuno Teixeira" > ; > Sent: Thursday, August 09, 2001 10:40 PM > Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... > > > > Hmm.. I only update the 'world' if I am changing something that requires > > it, other then that I use a crontab entry that looks similiar to this.. > > > > #run cvsup every week at 2:30 AM (Friday) + compile/install new kernel > > 30 2 * * 5 root newkernel > > > > and the newkernel script is as follows.. > > > > #!/bin/sh > > # New kernel script, will cvsup, configure, compiling and install > > # new kernel from source. -erb > > # > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin > > export PATH > > cvsup -g -L 2 /etc/supfile >/var/tmp/cvsup.out 2>&1 > > cd /usr/src/sys/i386/conf > > config CLOUD9 >/var/tmp/config.out 2>&1 > > cd /usr/src > > make update >/var/tmp/update.out 2>&1 > > #make buildworld >/var/tmp/buildworld.out 2>&1 > > #make installworld >/var/tmp/installworld.out 2>&1 > > make buildkernel KERNCONF=CLOUD9 >/var/tmp/buildkernel.out 2>&1 > > make installkernel KERNCONF=CLOUD9 >/var/tmp/installkernel.out 2>&1 > > echo "CVSUp, & Kernel compile/install completed. For more information > > referr to /var/tmp and browse through the .out files." | mail -s "cvsup & > kernel compile completed" sysadmin@cloud9.pain.net > > > > seems to do the trick just fine, could anyone let me know if this is a bad > > idea? > > > > On Thu, 9 Aug 2001, Jim Durham wrote: > > > > > On Wed, 1 Aug 2001, Josef Karthauser wrote: > > > > > > > On Wed, Aug 01, 2001 at 10:01:41PM +0100, Nuno Teixeira wrote: > > > > > > > > > My question is: what is the real danger of doing `installworld` in > > > > > multiuser mode? I have doing a lot of tests in other machines > tracking > > > > > STABLE and I have no problems so far. > > > > > > > > I've _always_ done installworld in multiuser on many servers. That > > > > doesn't mean that it's the safest way, but it was safe enough for me. > > > > > > > > Joe > > > > > > > > > > Well, I got talked into trying this and it panic'd the running > > > kernel, so I won't do it that way again! I know lots of folks have > > > gotten away with this, but it seems to be Russian Roulette.. > > > > > > I now have a "boot.config" file with "-h" in it and a null modem > > > cable to my portmaster. I reboot into single-user, telnet into > > > the portmaster and get on the serial port. Works very well. > > > You could also cross-connect serial ports from another server. > > > > > > -Jim Durham > > > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-security" in the body of the message > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 0: 2: 0 2001 Delivered-To: freebsd-security@freebsd.org Received: from cloud9.pain.net (cloud9.pain.net [209.58.150.180]) by hub.freebsd.org (Postfix) with ESMTP id F20AA37B401 for ; Fri, 10 Aug 2001 00:01:55 -0700 (PDT) (envelope-from erb@cloud9.pain.net) Received: from localhost (erb@localhost) by cloud9.pain.net (8.11.5/8.11.1) with ESMTP id f7A71ld57451; Fri, 10 Aug 2001 03:01:48 -0400 (EDT) (envelope-from erb@cloud9.pain.net) Date: Fri, 10 Aug 2001 03:01:47 -0400 (EDT) From: erb To: alexus Cc: Jim Durham , Josef Karthauser , Nuno Teixeira , Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... In-Reply-To: <002501c1214d$07a5cf70$0100a8c0@alexus> Message-ID: 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 The machine isnt doing much at that time, and having the current sources is always a nice idea, I make sure to check the update files and such if/before I boot the new kernel. It helps to cut back on crusty broken lib's and add's security & bug fixes.. :) On Thu, 9 Aug 2001, alexus wrote: > i'm more or less newbie here > > can you explain me why would you ever want to > > do cvsup+rebuild kernel every friday? what's wrong with your old kernel? > > ----- Original Message ----- > From: "erb" > To: "Jim Durham" > Cc: "Josef Karthauser" ; "Nuno Teixeira" > ; > Sent: Thursday, August 09, 2001 10:40 PM > Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... > > > > Hmm.. I only update the 'world' if I am changing something that requires > > it, other then that I use a crontab entry that looks similiar to this.. > > > > #run cvsup every week at 2:30 AM (Friday) + compile/install new kernel > > 30 2 * * 5 root newkernel > > > > and the newkernel script is as follows.. > > > > #!/bin/sh > > # New kernel script, will cvsup, configure, compiling and install > > # new kernel from source. -erb > > # > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin > > export PATH > > cvsup -g -L 2 /etc/supfile >/var/tmp/cvsup.out 2>&1 > > cd /usr/src/sys/i386/conf > > config CLOUD9 >/var/tmp/config.out 2>&1 > > cd /usr/src > > make update >/var/tmp/update.out 2>&1 > > #make buildworld >/var/tmp/buildworld.out 2>&1 > > #make installworld >/var/tmp/installworld.out 2>&1 > > make buildkernel KERNCONF=CLOUD9 >/var/tmp/buildkernel.out 2>&1 > > make installkernel KERNCONF=CLOUD9 >/var/tmp/installkernel.out 2>&1 > > echo "CVSUp, & Kernel compile/install completed. For more information > > referr to /var/tmp and browse through the .out files." | mail -s "cvsup & > kernel compile completed" sysadmin@cloud9.pain.net > > > > seems to do the trick just fine, could anyone let me know if this is a bad > > idea? > > > > On Thu, 9 Aug 2001, Jim Durham wrote: > > > > > On Wed, 1 Aug 2001, Josef Karthauser wrote: > > > > > > > On Wed, Aug 01, 2001 at 10:01:41PM +0100, Nuno Teixeira wrote: > > > > > > > > > My question is: what is the real danger of doing `installworld` in > > > > > multiuser mode? I have doing a lot of tests in other machines > tracking > > > > > STABLE and I have no problems so far. > > > > > > > > I've _always_ done installworld in multiuser on many servers. That > > > > doesn't mean that it's the safest way, but it was safe enough for me. > > > > > > > > Joe > > > > > > > > > > Well, I got talked into trying this and it panic'd the running > > > kernel, so I won't do it that way again! I know lots of folks have > > > gotten away with this, but it seems to be Russian Roulette.. > > > > > > I now have a "boot.config" file with "-h" in it and a null modem > > > cable to my portmaster. I reboot into single-user, telnet into > > > the portmaster and get on the serial port. Works very well. > > > You could also cross-connect serial ports from another server. > > > > > > -Jim Durham > > > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-security" in the body of the message > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 1: 9:27 2001 Delivered-To: freebsd-security@freebsd.org Received: from mbox-r00.iij.ad.jp (mbox-r00.iij.ad.jp [210.130.1.14]) by hub.freebsd.org (Postfix) with ESMTP id 44B2E37B401 for ; Fri, 10 Aug 2001 01:09:24 -0700 (PDT) (envelope-from vinesp@ab.inbox.ne.jp) Received: from pc06 (h114.n004.fair.iijnet.or.jp [210.130.158.114]) by mbox-r00.iij.ad.jp (8.8.8+2.2IIJ/3.7W-RELAY1.1) with SMTP id RAA13295 for ; Fri, 10 Aug 2001 17:09:23 +0900 (JST) Date: Fri, 10 Aug 2001 17:08:00 +0900 From: Vine Sp To: freebsd-security@FreeBSD.ORG Message-Id: <3B739660D.CF8BVINESP@mbox.iij.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.26.05 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 auth 1717dc26 unsubscribe freebsd-security vinesp@ab.inbox.ne.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 1:24:30 2001 Delivered-To: freebsd-security@freebsd.org Received: from phoenix.tricom.com.ph (phoenix.tricom.com.ph [203.167.87.58]) by hub.freebsd.org (Postfix) with SMTP id 2E34E37B405 for ; Fri, 10 Aug 2001 01:24:19 -0700 (PDT) (envelope-from jimmy@tricom.com.ph) Received: (qmail 28638 invoked from network); 10 Aug 2001 08:27:34 -0000 Received: from sphinx.tricom.com.ph (HELO tricom.com.ph) (@203.167.87.59) by tricom.com.ph with SMTP; 10 Aug 2001 08:27:34 -0000 Message-ID: <3B739D78.73F7F575@tricom.com.ph> Date: Fri, 10 Aug 2001 16:38:16 +0800 From: Jimmy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-pre4 i686) X-Accept-Language: en MIME-Version: 1.0 To: security@freebsd.org 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 1:32:26 2001 Delivered-To: freebsd-security@freebsd.org Received: from Yellow.japan-telecom.co.jp (Yellow.japan-telecom.co.jp [210.146.35.35]) by hub.freebsd.org (Postfix) with ESMTP id 8B96737B406 for ; Fri, 10 Aug 2001 01:32:22 -0700 (PDT) (envelope-from hmiura@japan-telecom.co.jp) Received: from japan-telecom.co.jp (localhost [127.0.0.1]) by Yellow.japan-telecom.co.jp (3.7W-Yellow) with ESMTP id f7A8WLk18645 for ; Fri, 10 Aug 2001 17:32:21 +0900 (JST) Received: (from root@localhost) by japan-telecom.co.jp (3.7W-SP340201) id RAA07174 for ; Fri, 10 Aug 2001 17:32:47 +0900 (JST) Received: from unknown [172.16.237.100] by SP340201.japan-telecom.co.jp with SMTP id TAA07171 ; Fri, 10 Aug 2001 17:32:47 +0900 Message-ID: <3B739BF7.61AB1561@japan-telecom.co.jp> Date: Fri, 10 Aug 2001 17:31:51 +0900 From: "H,Miura" X-Mailer: Mozilla 4.04 [ja] (Win95; I) MIME-Version: 1.0 To: freebsd-security@FreeBSD.org Content-Type: text/plain; charset=iso-2022-jp 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 auth be27a2ae subscribe freebsd-security hmiura@japan-telecom.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 4: 1:28 2001 Delivered-To: freebsd-security@freebsd.org Received: from pa169.kurdwanowa.sdi.tpnet.pl (pa169.kurdwanowa.sdi.tpnet.pl [213.77.148.169]) by hub.freebsd.org (Postfix) with ESMTP id 3DAD337B401 for ; Fri, 10 Aug 2001 03:59:00 -0700 (PDT) (envelope-from kzaraska@student.uci.agh.edu.pl) Received: by pa169.kurdwanowa.sdi.tpnet.pl (Postfix, from userid 1001) id B60971C87; Fri, 10 Aug 2001 12:54:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by pa169.kurdwanowa.sdi.tpnet.pl (Postfix) with ESMTP id 0C81D5493; Fri, 10 Aug 2001 12:54:24 +0200 (CEST) Date: Fri, 10 Aug 2001 12:54:24 +0200 (CEST) From: Krzysztof Zaraska X-Sender: kzaraska@lhotse.zaraska.dhs.org To: Tony Landells Cc: freebsd-security@FreeBSD.ORG Subject: Re: distributed natd In-Reply-To: <200108100115.LAA20997@tungsten.austclear.com.au> Message-ID: 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 On Fri, 10 Aug 2001, Tony Landells wrote: > The idea is to run two (or more) firewalls in parallel in such a way > that if one failed the other one would pick up the slack without users > noticing. Seems interesting. First, I'd recommend taking at look at IPFILTER. Its nat implementation has few interesting concepts, including restricting outgoing port range and viewing state table. There were however some lincensing problems with this code recently, IIRC. > Obviously, this wouldn't work terribly well with stateful packet > filtering... Could work. I don't see much difference between updating nat dynamic rules and filtering dynamic rules. > I haven't even begun to look at the code for natd, but can anyone > see any fatal flaws in the concept? So I guess that you want to make your firewalls to exchange information about changes in state tables, right? In my opinion both firewalls should communicate over a secure link to avoid fooling them by someone. Theoretically you could use SSL connections but I guess it would consume too much computing power. I would make them communicate over a separate cable (i.e. a small Ethernet connecting only firewalls). Next, I don't know whether they should communicate over TCP or UDP. I would use UDP since it might be faster and it allows broadcasts (one firewall broadcasting changes to all others on the secure network) but is unreliable. A persistent TCP connection may be also considered. Next, I don't know if it is necessary to hack the firewall code. You could probably escape (at least with slow link and fast machines) with an userland daemon watching / updating state table an communicating over secure network. It is however not clean to me how and how often you want to check if firewall is alive. Also it needs to be considered what happens in case one of the firewalls is compromised. I guess this implies compromise of all firewalling machines. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 5:25:44 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id E237B37B406 for ; Fri, 10 Aug 2001 05:25:38 -0700 (PDT) (envelope-from fschapachnik@vianetworks.com.ar) Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.9.3/8.9.3) id JAA81109; Fri, 10 Aug 2001 09:24:39 -0300 (ART) X-Authentication-Warning: ns1.via-net-works.net.ar: fpscha set sender to fschapachnik@vianetworks.com.ar using -f Date: Fri, 10 Aug 2001 09:24:39 -0300 From: Fernando Schapachnik To: Jon Loeliger Cc: security@FreeBSD.ORG Subject: Re: IPFW Dynamic Rules Message-ID: <20010810092439.B76214@ns1.via-net-works.net.ar> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdl@jdl.com on Thu, Aug 09, 2001 at 09:33:10PM -0500 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 En un mensaje anterior, Jon Loeliger escribió: > keep-state [method] > Upon a match, the firewall will create a dynamic rule, > whose default behaviour is to matching bidirectional > traffic between source and destination IP/port using the > same protocol. The rule has a limited lifetime (con- > trolled by a set of sysctl(8) variables), and the life- > time is refreshed every time a matching packet is found. > > So if the dynamic rule has the same behaviour as the origination > rule on the same port with the same protocol, why can't packets > simply continue to be matched against that original base rule? Because it does it bidirectionaly. Ie, if you keep-state on outgoing, the the reply (assuming it swaps origin-destination ports) will also be allowed. Another difference it that it ignores, eg, TCP flags. It means you setup a keep-state rule to match the original SYN and then the rest of the flow gets permitted. > Why does the dynamic rule even need to come into existence? > > How many dynamic rules do you need to allow for, roughly, based on > some simple system paramters? Pure heuristic and guess work here? > Markov chain arrival rate rule decay rate blah blah tune it blah blah? > I filled the default 256 readily, and bumped it to 1024 on a whim. Empirically, our busy servers (5 of them) need 1500-2000 dynamic rules. Of course, that depends on your traffic. Regards. Fernando P. Schapachnik Planificación de red y tecnología VIA NET.WORKS ARGENTINA S.A. fschapachnik@vianetworks.com.ar Tel.: (54-11) 4323-3381 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 5:33:13 2001 Delivered-To: freebsd-security@freebsd.org Received: from pa169.kurdwanowa.sdi.tpnet.pl (pa169.kurdwanowa.sdi.tpnet.pl [213.77.148.169]) by hub.freebsd.org (Postfix) with ESMTP id 78E5A37B40B for ; Fri, 10 Aug 2001 05:33:09 -0700 (PDT) (envelope-from kzaraska@student.uci.agh.edu.pl) Received: by pa169.kurdwanowa.sdi.tpnet.pl (Postfix, from userid 1001) id 1B44C1C88; Fri, 10 Aug 2001 14:33:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by pa169.kurdwanowa.sdi.tpnet.pl (Postfix) with ESMTP id CB15C5493 for ; Fri, 10 Aug 2001 14:33:45 +0200 (CEST) Date: Fri, 10 Aug 2001 14:33:45 +0200 (CEST) From: Krzysztof Zaraska X-Sender: kzaraska@lhotse.zaraska.dhs.org To: freebsd-security@freebsd.org Subject: Re: Separate firewall or not...OOPS no subject sorry! In-Reply-To: <20010810031430.S3889@gnjilux.cc.fer.hr> Message-ID: 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 On Fri, 10 Aug 2001, Ivan Krstic wrote: > On Fri, Aug 10, 2001 at 10:47:49AM +1000, Keith Spencer wrote: > > Should I build a separate preimeter firewall machine > > with only that on it...restrict/remove compilers etc > > (how do I do that?) and have the router/dns/web/wail > > server inside the perimeter. > > This would be the most desired solution, if you have the resources to spare for > a separate firewall machine. If this machine would serve no other purpose > beside being a firewall, just about any old box (PI) will do for SOHOs. Also see Chapman, "Building Internet Firewalls". There's some good stuff about firewall design as itself. Specifically, they recommend building perimeter network and moving all services there and placing all other machines on the internal network. So if a server is compromised, still there's a firewall to go between the attacker and internal network. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 5:47:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from purgatory.unfix.org (purgatory.xs4all.nl [194.109.237.229]) by hub.freebsd.org (Postfix) with ESMTP id D36AD37B401 for ; Fri, 10 Aug 2001 05:47:12 -0700 (PDT) (envelope-from jeroen@unfix.org) Received: from cyan (gateway.azr.nl [::ffff:156.83.254.8]) by purgatory.unfix.org (Postfix) with ESMTP id BCF3A313E; Fri, 10 Aug 2001 14:47:06 +0200 (CEST) From: "Jeroen Massar" To: "'Krzysztof Zaraska'" , "'Tony Landells'" Cc: Subject: RE: distributed natd Date: Fri, 10 Aug 2001 14:47:14 +0200 Organization: Unfix Message-ID: <000701c1219a$96206470$2a1410ac@kei.azr.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 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, 10 August 2001, Krzysztof Zaraska wrote: > > On Fri, 10 Aug 2001, Tony Landells wrote: > > > The idea is to run two (or more) firewalls in parallel in such a way > > that if one failed the other one would pick up the slack without users noticing. > Seems interesting. :) I thought of something like this before myself but with a different viewing point in that every gateway machine has an uplink to a separate provider, but still to the global internet (eg, telephone and gsm and satelite and cable linkups :) This though also implies that we got multiple external IP's and thus sessions would be lost if an uplink would go down. My idea was to do the following setup: Inet <-----> ISP1 <----> (a.a.a.a) Gate1 (10.0.0.1) <---> LAN <-----> ISP2 <----> (b.b.b.b) Gate2 (10.0.0.2) <---> <-----> ISP3 <----> (c.c.c.c) Gate3 (10.0.0.3) <---> GateNet <---> (192.168.0.1) Gate1 <---> (192.168.0.2) Gate2 <---> (192.168.0.3) Gate3 Whenever ISP1's uplink would go down Gate1 would bring down it's 10.0.0.1 IP and notify this to Gate2 and Gate3 over GateNet, the fastest of the two would then alias Gate1's LanIP (10.0.0.1) and takeover it's service and so on. If Gate1 gets it's uplink back it would simply notify Gate2&3 who would bring down their 10.0.0.1 alias and Gate1 would bring it up again.... et tada we got redundancy. Client boxes on the LAN could have a 'preferred' gateway either Gate1,2,3 making some users go over the slowest line etc. Packets could also be redirected over the Gatenet if needed... You could have PING's between the Gate's to check if the boxes itself are still alive etc... Ofcourse this basically comes down to routing though with BSD/* boxes and not redundant hardware routers (Cisco etc :) Instead of aliasing the Gate's LAN IP one could also send RouterRedirect ICMP's to the clients. If one has the same outside IP on the gates.... you could transfer states between the boxes and keep on doing stuff. But I would only use that for redundant linkups. The hardware and OS should be 'trusted' to keep on running then :) Greets, Jeroen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 6: 2:50 2001 Delivered-To: freebsd-security@freebsd.org Received: from pa169.kurdwanowa.sdi.tpnet.pl (pa169.kurdwanowa.sdi.tpnet.pl [213.77.148.169]) by hub.freebsd.org (Postfix) with ESMTP id 2A51C37B405 for ; Fri, 10 Aug 2001 06:02:31 -0700 (PDT) (envelope-from kzaraska@student.uci.agh.edu.pl) Received: by pa169.kurdwanowa.sdi.tpnet.pl (Postfix, from userid 1001) id AA69C1C87; Fri, 10 Aug 2001 14:23:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by pa169.kurdwanowa.sdi.tpnet.pl (Postfix) with ESMTP id 4B05A5493; Fri, 10 Aug 2001 14:23:57 +0200 (CEST) Date: Fri, 10 Aug 2001 14:23:56 +0200 (CEST) From: Krzysztof Zaraska X-Sender: kzaraska@lhotse.zaraska.dhs.org To: Jon Loeliger Cc: security@FreeBSD.ORG Subject: Re: IPFW Dynamic Rules In-Reply-To: Message-ID: 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 On Thu, 9 Aug 2001, Jon Loeliger wrote: > So if the dynamic rule has the same behaviour as the origination > rule on the same port with the same protocol, why can't packets > simply continue to be matched against that original base rule? > Why does the dynamic rule even need to come into existence? It does not have _the same_ behavior. Simply speaking, if you add keep-state to the rule it means "pass the packet which is a reply to this one". Assuming x.x.x.x is your ip, z.z.z.z is outside (client) ip. If client sends UDP query to DNS on your machine, you get the packet: z.z.z.z:z -> x.x.x.x:53 INCOMING Yet in yor machine's reply x.x.x.x:53 -> z.z.z.z:z OUTGOING Firewall code matches data from IP/TCP/UDP header to the ruleset. If ALL fields in packet match those in the rule the specified action (allow, deny, deny & log, etc.) is triggered. So if you have a rule "allow INCOMING packet from ANY host ANY port to z.z.z.z port 53" it will pass the first packet. But the reply packet is an OUTGOING packet from x.x.x.x:53 to z.z.z.z:z so it _doesn't_ match the rule. And now what keep-state does: In our example, if you have the same rule as above but with keep-state, after the rule is matched and packet is let through, a new rule is added saying: "allow OUTGOING packet from x.x.x.x port 53 to z.z.z.z port z" and this will match exactly the reply packet. Dynamic rules are deleted after a given period of time. More typical use of this is: add pass udp from yourip to any keep-state so you may initiate UDP queries and the replies will be allowed back, without keep-state they would be dropped. If you're running a public DNS for example, you may just allow all traffic to (queries to your server) port 53 and from port 53 (replies from your server). > How many dynamic rules do you need to allow for, roughly, based on > some simple system paramters? Pure heuristic and guess work here? > Markov chain arrival rate rule decay rate blah blah tune it blah blah? > I filled the default 256 readily, and bumped it to 1024 on a whim. One active connection = one dynamic rule. Also take into account the rule is deleted after connection is inactive for some time. I generally use keep-state for UDP traffic, not for TCP. ipfw can inspect the state of TCP connection, so there is a better way (see below). > So I think I may be doing something vaguely Not Quite Right with > some "keep-state" rules too. I think I got to this NQR state due > to some early wrong rule tinkering. To be concrete: > > I first made the mistake of being too uni-directional and had a > rule like this, intending to mean "anything that is established > between the Big Bad Outside and my net, let it through." > > 00800 allow tcp from any to MY_REAL_NET/MASK established > > and this one intended to allow access to a web server: > > 01200 allow tcp from any to 209.39.144.0/27 80 setup First, a brief explanation of TCP: BEFORE ANYTHING can be sent over a TCP connection, a connection MUST be stablished. The procedure is as follows (client connects to server): 1. client sents the packet with the SYN flag sent 2. if server wishes to open this connection, it replies with packet with both flags SYN and ACK set; if it doesn't wish to open the connection (e.g. no httpd running), it replies with packet with set both RST and ACK flags. 3. if client received SYN+ACK packet (=server wants to talk) it replies with a packet with ACK flag set. CONNECTION ESTABLISHED. 4. all packets exchanged between client and server have ACK flag set. The idea behind example in /etc/rc.firewall is: we allow _all_ ESTABLISHED connections and control only the SETUP of new connections. Since nothing may be sent without prior establishing the session (steps 1-3 above) this provides adequate security. In other words: allow all packets with ACKs, control only SYNs. So the rules read (/etc/rc.firewall, CLIENT section): # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established Then # Allow setup of incoming email ${fwcmd} add pass tcp from any to ${ip} 25 setup At this point we allow only incoming SYNs to port 25, that is, the only connection that may be established is this to port 25. Any other SYNs sent by the client will be dropped and the client never receives SYN+ACK. A SYN to port 25 will generate the reply of SYN+ACK which will be passed by the "established" rule above. Later we must allow ourselves to initiate the connections, so we have: # Allow setup of outgoing TCP connections only ${fwcmd} add pass tcp from ${ip} to any setup Assuming everything else is blocked, we end up with: connections to port 25 allowed from outside, we may connect to everybody else, any other connection attempts to us are forbidden. Guess this is what you want. UDP unfortunately, does not define connections, so we must use the keep-state technique as above. With TCP there's no need for that, since you may allow all enstablished connections and filter only connection requests. > What I need to do is change the 800 rule to be: > > 00800 allow tcp from any to any established > > and take the keep-state off the 1200 rule again: > > 01200 allow tcp from any to MY_REAL_NET/MASK 80 setup Exactly! (see above) Generally I construct firewall rules like this: 1. deny everything 2. allow all connections from inside to outside world. TEST. 3. allow the outside world to connect to selected services. TEST. 4. TEST. Specifically check if no unwanted connections may be initiated from outside. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 9:27: 6 2001 Delivered-To: freebsd-security@freebsd.org Received: from red.whoowl.com (dsl-65-184-21-205.telocity.com [65.184.21.205]) by hub.freebsd.org (Postfix) with SMTP id BFA1E37B409 for ; Fri, 10 Aug 2001 09:27:01 -0700 (PDT) (envelope-from jvb@whoowl.com) Received: (qmail 18647 invoked by uid 85); 10 Aug 2001 16:27:06 -0000 Received: from jvb@whoowl.com by red.whoowl.com with qmail-scanner-0.96 (hbedv: 6.8.0.0. . Clean. Processed in 1.905195 secs); 10 Aug 2001 16:27:06 -0000 X-Qmail-Scanner-Mail-From: jvb@whoowl.com via red.whoowl.com X-Qmail-Scanner-Rcpt-To: freebsd-security@FreeBSD.ORG X-Qmail-Scanner: 0.96 (No viruses found. Processed in 1.905195 secs) Received: from unknown (HELO black) (192.168.0.107) by dsl-65-184-21-205.telocity.com with SMTP; 10 Aug 2001 16:27:02 -0000 Message-ID: <010c01c121b9$461f3040$6b00a8c0@vanbo.whoowl.com> From: "John Van Boxtel" Cc: References: Subject: Re: distributed natd Date: Fri, 10 Aug 2001 09:26:56 -0700 Organization: Whoowl.com X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 > Next, I don't know whether they should communicate over TCP or UDP. I > would use UDP since it might be faster and it allows broadcasts (one > firewall broadcasting changes to all others on the secure network) but is > unreliable. A persistent TCP connection may be also considered. The persistent TCP connection could be used well as if the connection dropped this could signal that the other gateway is down for whatever reason. This would not be useful for telling if that gateway no longer has an upstream connection but it would definitely let you know that the gateway is no longer availible (ie power lost, hardware failuer, etc) > It is however not clean to me how and how often you want to check if > firewall is alive. See above, this would instantly, let you know it's gone, but it would only tell you that the gateway is dead not when the gateway is up but its upstream is down. Interesting stuff :-) JVB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 9:58:33 2001 Delivered-To: freebsd-security@freebsd.org Received: from mbs.microbiz.net (mbs.microbiz.net [204.244.63.1]) by hub.freebsd.org (Postfix) with ESMTP id 845A437B432 for ; Fri, 10 Aug 2001 09:58:20 -0700 (PDT) (envelope-from kulraj@microbiz.net) Received: from kulraj (ws101.mbs-lan [10.0.0.101]) by mbs.microbiz.net (Postfix) with SMTP id CDA2D592DC for ; Fri, 10 Aug 2001 09:58:19 -0700 (PDT) Message-ID: <003601c1228d$090a2f00$6500000a@kulraj> From: "Kulraj Gurm" To: References: Subject: Code Red Autoresponder Date: Sat, 11 Aug 2001 10:42:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Haven't tried this; but sound really slick! http://www.klippan.seths.se/default.phps To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 11:48: 4 2001 Delivered-To: freebsd-security@freebsd.org Received: from pa169.kurdwanowa.sdi.tpnet.pl (pa169.kurdwanowa.sdi.tpnet.pl [213.77.148.169]) by hub.freebsd.org (Postfix) with ESMTP id 3826C37B401 for ; Fri, 10 Aug 2001 11:48:00 -0700 (PDT) (envelope-from kzaraska@student.uci.agh.edu.pl) Received: by pa169.kurdwanowa.sdi.tpnet.pl (Postfix, from userid 1001) id D4DE81C88; Fri, 10 Aug 2001 20:48:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by pa169.kurdwanowa.sdi.tpnet.pl (Postfix) with ESMTP id 830385493; Fri, 10 Aug 2001 20:48:32 +0200 (CEST) Date: Fri, 10 Aug 2001 20:48:32 +0200 (CEST) From: Krzysztof Zaraska X-Sender: kzaraska@lhotse.zaraska.dhs.org To: John Van Boxtel Cc: freebsd-security@FreeBSD.ORG Subject: Re: distributed natd In-Reply-To: <010c01c121b9$461f3040$6b00a8c0@vanbo.whoowl.com> Message-ID: 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 On Fri, 10 Aug 2001, John Van Boxtel wrote: > > Next, I don't know whether they should communicate over TCP or UDP. I > > would use UDP since it might be faster and it allows broadcasts (one > > firewall broadcasting changes to all others on the secure network) but is > > unreliable. A persistent TCP connection may be also considered. > > The persistent TCP connection could be used well as if the connection > dropped this could signal that the other gateway is down for whatever > reason. Not quite, I'm afraid. If a host shuts down it will close open connections; yet if it dies suddenly (power down, cable cut, etc.) you will get connection timeout. Unfortunately we should switch gateways ASAP after failure. Standard TCP timeout seems too long for me. Do you know any way to shorten this time? Therefore I would rather make gateways "ping" each other over the link say once a second. There's a technique IRC servers use to check if client is still alive: once a minute or so they send the client a "PING" command; if the client does not say "PONG" without given interval they assume it's dead an shut down the connection. Something like that could be used here. Of course if TCP connection shuts down it would also signal that something is wrong. > This would not be useful for telling if that gateway no longer has > an upstream connection If a gateway is alive and looses it's upstream connection and knows it (interface down, inability to ping next router, etc.) it could detect it and send the appropriate message to peer gateways. > Interesting stuff :-) Yeah. I like this subject too. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 12:39: 4 2001 Delivered-To: freebsd-security@freebsd.org Received: from w2xo.pgh.pa.us (18.gibs5.xdsl.nauticom.net [209.195.184.19]) by hub.freebsd.org (Postfix) with ESMTP id 462D137B403 for ; Fri, 10 Aug 2001 12:39:00 -0700 (PDT) (envelope-from durham@w2xo.pgh.pa.us) Received: from localhost (localhost [127.0.0.1]) by w2xo.pgh.pa.us (8.11.3/8.11.3) with ESMTP id f7AJtIm95409; Fri, 10 Aug 2001 15:55:19 -0400 (EDT) (envelope-from durham@w2xo.pgh.pa.us) Date: Fri, 10 Aug 2001 15:55:18 -0400 (EDT) From: Jim Durham To: alexus Cc: erb , Josef Karthauser , Nuno Teixeira , freebsd-security@FreeBSD.ORG Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... In-Reply-To: <002501c1214d$07a5cf70$0100a8c0@alexus> Message-ID: 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 On Thu, 9 Aug 2001, alexus wrote: > i'm more or less newbie here > > can you explain me why would you ever want to > > do cvsup+rebuild kernel every friday? what's wrong with your old kernel? > The tag "RELENG_4_3" means that cvsup only incorporates security fixes to the kernel. This is meant for "production servers", where you want to fool around with things the least amount possible. "If it ain't broke, don't fix it" . 8-) . This is about the only way to keep up with security fixes properly. There's a new exploit happening all the time. Actually, I watch this list for advisories and then do a cvsup. I don't do it on a schedule, but others do. As I said, I'm leery of updating a system running multi-user. I'm too old for the adrelelin rush -Jim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 13:18: 8 2001 Delivered-To: freebsd-security@freebsd.org Received: from nova.fnal.gov (nova.fnal.gov [131.225.121.207]) by hub.freebsd.org (Postfix) with ESMTP id 6046B37B405 for ; Fri, 10 Aug 2001 13:18:05 -0700 (PDT) (envelope-from zingelman@fnal.gov) Received: from localhost (tez@localhost) by nova.fnal.gov (8.9.3+Sun/8.9.3) with ESMTP id PAA18194; Fri, 10 Aug 2001 15:17:36 -0500 (CDT) X-Authentication-Warning: nova.fnal.gov: tez owned process doing -bs Date: Fri, 10 Aug 2001 15:17:36 -0500 (CDT) From: Tim Zingelman X-Sender: To: Jim Durham Cc: alexus , erb , Josef Karthauser , Nuno Teixeira , Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... In-Reply-To: Message-ID: 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 On Fri, 10 Aug 2001, Jim Durham wrote: > The tag "RELENG_4_3" means that cvsup only incorporates security > fixes to the kernel. This is false. RELENG_4_3 includes critical security fixes in BOTH kernel and userland. It is NOT always safe to only rebuild your kernel if you are updating to RELENG_4_3. I cite as a reference this message from Kris Kennaway: http://groups.yahoo.com/group/freebsd-stable/message/39749 - Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 13:38: 1 2001 Delivered-To: freebsd-security@freebsd.org Received: from comnet.ca (comnet.ca [216.191.240.2]) by hub.freebsd.org (Postfix) with ESMTP id 5D87737B407 for ; Fri, 10 Aug 2001 13:37:44 -0700 (PDT) (envelope-from webdesigns@comnet.ca) Received: from critter (64.39.176.9.comnet.ca [64.39.176.9]) by comnet.ca (8.11.3/8.11.3) with SMTP id f7AKbcY01997 for ; Fri, 10 Aug 2001 16:37:38 -0400 (EDT) Message-ID: <002c01c121dc$2b7a4680$0200000a@critter> From: "webdesigns COMNET" To: Subject: HELP PLEASE!! Date: Fri, 10 Aug 2001 16:36:39 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C121BA.A0F26B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C121BA.A0F26B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: ShellsAndHosting.com Administration=20 To: freebsd-security@FreeBSD.ORG=20 Sent: Friday, August 10, 2001 9:04 AM Subject: routing Hi, Can someone help me figure out a solution? Here is the setup: modem <-> FreeBSD Gateway <-> switch <-> Lan I would like to forward all request from 64.39.183.78 to a lan client = 10.0.0.3 I have tried using -redirect_address 10.0.0.3 64.39.183.78 with natd, = but it won't work. Any clue why? Interface sis0 is the public interface with 32 ips on it, i would like = to route a few of thoose ips through rl0 (the internal interface) to my = other lan machines. What and how would be my best way? ------=_NextPart_000_0029_01C121BA.A0F26B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----=20
From: ShellsAndHosting.com = Administration
Sent: Friday, August 10, 2001 9:04 AM
Subject: routing

Hi,
Can someone help me figure out a=20 solution?
Here is the setup:  modem = <-> FreeBSD=20 Gateway <-> switch <-> Lan
I would like to forward all request = from=20 64.39.183.78 to a lan client 10.0.0.3
I have tried using -redirect_address = 10.0.0.3=20 64.39.183.78 with natd, but it won't work. Any clue why?
Interface sis0 is the public interface = with 32 ips=20 on it, i would like to route a few of thoose ips through rl0 (the = internal=20 interface) to my other lan machines.
What and how would be my best = way?
 
 
 
 
------=_NextPart_000_0029_01C121BA.A0F26B80-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 14: 3:57 2001 Delivered-To: freebsd-security@freebsd.org Received: from jdl.com (chrome.jdl.com [209.39.144.2]) by hub.freebsd.org (Postfix) with ESMTP id B046537B406 for ; Fri, 10 Aug 2001 14:03:53 -0700 (PDT) (envelope-from jdl@jdl.com) Received: from localhost ([127.0.0.1] helo=jdl.com) by jdl.com with esmtp (Exim 3.32 #1) id 15VJWU-000J6t-00; Fri, 10 Aug 2001 16:08:50 -0500 To: Krzysztof Zaraska Cc: security@FreeBSD.ORG Subject: Re: IPFW Dynamic Rules In-reply-to: Your message of "Fri, 10 Aug 2001 14:23:56 +0200." Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Fri, 10 Aug 2001 16:08:48 -0500 From: Jon Loeliger Message-Id: 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 So, like Krzysztof Zaraska was saying to me just the other day: > > [ ... ] > > Generally I construct firewall rules like this: > 1. deny everything > 2. allow all connections from inside to outside world. TEST. > 3. allow the outside world to connect to selected services. TEST. > 4. TEST. Specifically check if no unwanted connections may be initiated > from outside. Krzysztof, This was one of the most enlightening and helpful explanations of IPFW and packet filtering I've read anywhere! Thanks for the insight and help! jdl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 16:18:26 2001 Delivered-To: freebsd-security@freebsd.org Received: from cloud9.pain.net (cloud9.pain.net [209.58.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 7E67C37B406 for ; Fri, 10 Aug 2001 16:18:20 -0700 (PDT) (envelope-from erb@cloud9.pain.net) Received: from localhost (erb@localhost) by cloud9.pain.net (8.11.5/8.11.1) with ESMTP id f7ANIEV68304; Fri, 10 Aug 2001 19:18:14 -0400 (EDT) (envelope-from erb@cloud9.pain.net) Date: Fri, 10 Aug 2001 19:18:13 -0400 (EDT) From: erb To: Tim Zingelman Cc: Jim Durham , alexus , Josef Karthauser , Nuno Teixeira , Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... In-Reply-To: Message-ID: 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 If we are referring to the topic I brought up about my newkernel script earlier, I use the RELENG_4 tag, which I believe is safe to only rebuild the kernel for. On Fri, 10 Aug 2001, Tim Zingelman wrote: > On Fri, 10 Aug 2001, Jim Durham wrote: > > > The tag "RELENG_4_3" means that cvsup only incorporates security > > fixes to the kernel. > > This is false. RELENG_4_3 includes critical security fixes in BOTH kernel > and userland. It is NOT always safe to only rebuild your kernel if you > are updating to RELENG_4_3. > > I cite as a reference this message from Kris Kennaway: > > http://groups.yahoo.com/group/freebsd-stable/message/39749 > > - Tim > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 16:52: 2 2001 Delivered-To: freebsd-security@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-82.dsl.lsan03.pacbell.net [63.207.60.82]) by hub.freebsd.org (Postfix) with ESMTP id 7FFAA37B401 for ; Fri, 10 Aug 2001 16:51:59 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 7BE2566C4D; Fri, 10 Aug 2001 16:22:54 -0700 (PDT) Date: Fri, 10 Aug 2001 16:22:53 -0700 From: Kris Kennaway To: erb Cc: Tim Zingelman , Jim Durham , alexus , Josef Karthauser , Nuno Teixeira , freebsd-security@FreeBSD.ORG Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... Message-ID: <20010810162253.A40854@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from erb@cloud9.pain.net on Fri, Aug 10, 2001 at 07:18:13PM -0400 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 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 10, 2001 at 07:18:13PM -0400, erb wrote: > If we are referring to the topic I brought up about my newkernel script > earlier, I use the RELENG_4 tag, which I believe is safe to only rebuild > the kernel for. Nope. You can't always get away with doing this in any branch of FreeBSD. Kris --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7dGzMWry0BWjoQKURAvLRAKDLcgatDX8/Y4j9y88u0pb7m1rsmACdHC5b z9cHJGSJTBz97QrBxiHxIUA= =+NDm -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 17:50:20 2001 Delivered-To: freebsd-security@freebsd.org Received: from comnet.ca (comnet.ca [216.191.240.2]) by hub.freebsd.org (Postfix) with ESMTP id E801D37B406 for ; Fri, 10 Aug 2001 17:50:05 -0700 (PDT) (envelope-from webdesigns@comnet.ca) Received: from critter (64.39.176.9.comnet.ca [64.39.176.9]) by comnet.ca (8.11.3/8.11.3) with SMTP id f7B0npv25852; Fri, 10 Aug 2001 20:49:53 -0400 (EDT) Message-ID: <001c01c121ff$6a1b84d0$0200000a@critter> From: "webdesigns COMNET" To: "Dave" Cc: References: <002c01c121dc$2b7a4680$0200000a@critter> <010d01c121dd$e6c8e8a0$3300a8c0@mandy> Subject: Re: HELP PLEASE!! Date: Fri, 10 Aug 2001 20:48:55 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C121DD.DEBAAEF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C121DD.DEBAAEF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for your reply. I tried what you suggested, and I'm still unable to direct incoming = traffic from 64.39.183.78 to the lan client 10.0.0.3.=20 Requests for 64.39.183.78 still goto the gateway box. Here is a few things that my help you determin the problem. [root@thunder:/etc]-> ifconfig -a sis0: flags=3D8843 mtu 1500 inet 64.39.179.9 netmask 0xffffff00 broadcast 64.39.179.255 inet 64.39.183.72 netmask 0xffffffff broadcast 64.39.183.72 inet 64.39.183.73 netmask 0xffffffff broadcast 64.39.183.73 inet 64.39.183.74 netmask 0xffffffff broadcast 64.39.183.74 inet 64.39.183.75 netmask 0xffffffff broadcast 64.39.183.75 inet 64.39.183.76 netmask 0xffffffff broadcast 64.39.183.76 inet 64.39.183.77 netmask 0xffffffff broadcast 64.39.183.77 inet 64.39.183.78 netmask 0xffffffff broadcast 64.39.183.78 inet 64.39.183.79 netmask 0xffffffff broadcast 64.39.183.79 ether 00:30:18:80:20:10 media: Ethernet autoselect (10baseT/UTP) status: active rl0: flags=3D8843 mtu 1500 inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255 ether 00:50:ba:86:16:47 media: Ethernet autoselect (100baseTX) status: active lo0: flags=3D8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 tun0: flags=3D8051 mtu 1492 inet 64.39.176.9 --> 64.39.160.16 netmask 0xff000000 Opened by PID 148 [root@thunder:/etc]-> netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif = Expire default speede01.access.go UGSc 36 61 tun0 10 link#2 UC 2 0 rl0 =3D> critter 0:50:ba:8a:c2:e4 UHLW 2 688 rl0 = 1158 chickalicious.com 0:50:ba:ea:60:36 UHLW 0 2 rl0 = 834 speede01.access.go 64.39.176.9 UH 43 0 tun0 64.39.179/24 link#1 UC 0 0 sis0 =3D> shellsandhosting.c link#1 UC 0 0 sis0 =3D> lightning/32 link#1 UC 0 0 sis0 =3D> this.is.a.vhost/32 link#1 UC 0 0 sis0 =3D> mainframe/32 link#1 UC 0 0 sis0 =3D> 64.39.183.76/32 link#1 UC 0 0 sis0 =3D> 64.39.183.77/32 link#1 UC 0 0 sis0 =3D> 64.39.183.78/32 link#1 UC 0 0 sis0 =3D> 64.39.183.79/32 link#1 UC 0 0 sis0 =3D> localhost localhost UH 1 73 lo0 [root@thunder:/etc]-> ipnat -l List of active MAP/Redirect filters: bimap sis0 10.0.0.3/32 -> 64.39.183.78/32 List of active sessions: [root@thunder:/etc]-> I have been trying for 3 days to route my webserver to the outside = world. All your help and input would be greatly appreciated. Jason ----- Original Message -----=20 From: Dave=20 To: webdesigns COMNET=20 Sent: Friday, August 10, 2001 4:49 PM Subject: Re: HELP PLEASE!! Hey, I would recommend using ipnat for one instead of natd (Part of IP = Filter). No particular reason, just a preference. Then its fairly simple, =20 =20 add ipnat_enable=3D"YES" to your /etc/rc.conf file. =20 then=20 echo "bimap sis0 10.0.0.3/32 -> 64.39.183.78/32" >> = /etc/ipnat.rules && ipnat -FC -f /etc/ipnat.rules =20 =20 Hope to have helped. --Dave. =20 ----- Original Message -----=20 From: ShellsAndHosting.com Administration=20 To: freebsd-security@FreeBSD.ORG=20 Sent: Friday, August 10, 2001 9:04 AM Subject: routing Hi, Can someone help me figure out a solution? Here is the setup: modem <-> FreeBSD Gateway <-> switch <-> Lan I would like to forward all request from 64.39.183.78 to a lan = client 10.0.0.3 I have tried using -redirect_address 10.0.0.3 64.39.183.78 with = natd, but it won't work. Any clue why? Interface sis0 is the public interface with 32 ips on it, i would = like to route a few of thoose ips through rl0 (the internal interface) = to my other lan machines. What and how would be my best way? =20 =20 =20 =20 ------=_NextPart_000_0019_01C121DD.DEBAAEF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Dave,
 
Thanks for your = reply.
I tried what you suggested, and I'm = still unable to=20 direct incoming traffic from 64.39.183.78 to the lan client 10.0.0.3.=20
Requests for 64.39.183.78 still goto = the gateway=20 box.
 
Here is a few things that my help you = determin the=20 problem.
 
[root@thunder:/etc]-> ifconfig = -a
sis0:=20 flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu=20 1500
        inet 64.39.179.9 = netmask=20 0xffffff00 broadcast = 64.39.179.255
       =20 inet 64.39.183.72 netmask 0xffffffff broadcast=20 64.39.183.72
        inet = 64.39.183.73=20 netmask 0xffffffff broadcast=20 64.39.183.73
        inet = 64.39.183.74=20 netmask 0xffffffff broadcast=20 64.39.183.74
        inet = 64.39.183.75=20 netmask 0xffffffff broadcast=20 64.39.183.75
        inet = 64.39.183.76=20 netmask 0xffffffff broadcast=20 64.39.183.76
        inet = 64.39.183.77=20 netmask 0xffffffff broadcast=20 64.39.183.77
        inet = 64.39.183.78=20 netmask 0xffffffff broadcast=20 64.39.183.78
        inet = 64.39.183.79=20 netmask 0xffffffff broadcast=20 64.39.183.79
        ether=20 00:30:18:80:20:10
        media: = Ethernet=20 autoselect (10baseT/UTP)
        = status:=20 active
rl0: = flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu=20 1500
        inet 10.0.0.1 netmask = 0xff000000 broadcast=20 10.255.255.255
        ether=20 00:50:ba:86:16:47
        media: = Ethernet=20 autoselect (100baseTX)
        = status:=20 active
lo0: flags=3D8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu=20 16384
        inet 127.0.0.1 = netmask=20 0xff000000
tun0: flags=3D8051<UP,POINTOPOINT,RUNNING,MULTICAST> = mtu=20 1492
        inet 64.39.176.9 = -->=20 64.39.160.16 netmask = 0xff000000
       =20 Opened by PID 148
 
[root@thunder:/etc]-> netstat = -r
Routing=20 tables
 
Internet:
Destination      &nbs= p;=20 Gateway           = =20 Flags    Refs      Use  = Netif=20 Expire
default         &n= bsp; =20 speede01.access.go UGSc      =20 36       61  =20 tun0
10          &nb= sp;     =20 link#2           &= nbsp;=20 UC         =20 2        0    rl0=20 =3D>
critter         &= nbsp; =20 0:50:ba:8a:c2:e4   = UHLW       =20 2      688    rl0  =20 1158
chickalicious.com  0:50:ba:ea:60:36  =20 UHLW       =20 0        2   =20 rl0    834
speede01.access.go=20 64.39.176.9       =20 UH        =20 43        0  =20 tun0
64.39.179/24      =20 link#1           &= nbsp;=20 UC         =20 0        0   sis0=20 =3D>
shellsandhosting.c=20 link#1           &= nbsp;=20 UC         =20 0        0   sis0=20 =3D>
lightning/32      =20 link#1           &= nbsp;=20 UC         =20 0        0   sis0=20 =3D>
this.is.a.vhost/32=20 link#1           &= nbsp;=20 UC         =20 0        0   sis0=20 =3D>
mainframe/32      =20 link#1           &= nbsp;=20 UC         =20 0        0   sis0=20 =3D>
64.39.183.76/32   =20 link#1           &= nbsp;=20 UC         =20 0        0   sis0=20 =3D>
64.39.183.77/32   =20 link#1           &= nbsp;=20 UC         =20 0        0   sis0=20 =3D>
64.39.183.78/32   =20 link#1           &= nbsp;=20 UC         =20 0        0   sis0=20 =3D>
64.39.183.79/32   =20 link#1           &= nbsp;=20 UC         =20 0        0   sis0=20 =3D>
localhost         = ;=20 localhost         =20 UH         =20 1       73    = lo0
 
[root@thunder:/etc]-> ipnat = -l
List of active=20 MAP/Redirect filters:
bimap sis0 10.0.0.3/32  ->=20 64.39.183.78/32
 
List of active=20 sessions:
[root@thunder:/etc]->
I have been trying for 3 days to route = my webserver=20 to the outside world. All your help and input would be greatly=20 appreciated.
 
Jason

 
----- Original Message -----
From:=20 Dave
Sent: Friday, August 10, 2001 = 4:49=20 PM
Subject: Re: HELP = PLEASE!!

Hey,
    I would recommend = using ipnat=20 for one instead of natd (Part of  IP Filter).
    No particular = reason, just a=20 preference.
    Then its fairly=20 simple,
   
 
add ipnat_enable=3D"YES"
to your = /etc/rc.conf=20 file.
 
then
    echo "bimap=20 sis0 10.0.0.3/32 -> 64.39.183.78/32" >>=20 /etc/ipnat.rules && ipnat -FC -f = /etc/ipnat.rules
 
 
Hope to have helped.
--Dave.
 
----- Original Message -----
From: = ShellsAndHosting.com = Administration=20
Sent: Friday, August 10, 2001 9:04 AM
Subject: routing

Hi,
Can someone help me figure out a=20 solution?
Here is the setup:  modem = <->=20 FreeBSD Gateway <-> switch <-> Lan
I would like to forward all request = from=20 64.39.183.78 to a lan client 10.0.0.3
I have tried using = -redirect_address 10.0.0.3=20 64.39.183.78 with natd, but it won't work. Any clue = why?
Interface sis0 is the public = interface with 32=20 ips on it, i would like to route a few of thoose ips through rl0 = (the=20 internal interface) to my other lan machines.
What and how would be my best = way?
 
 
 
 
------=_NextPart_000_0019_01C121DD.DEBAAEF0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 18: 8:59 2001 Delivered-To: freebsd-security@freebsd.org Received: from unlink.catpipe.net (unlink.catpipe.net [195.249.214.172]) by hub.freebsd.org (Postfix) with ESMTP id A394C37B401 for ; Fri, 10 Aug 2001 18:08:55 -0700 (PDT) (envelope-from voland@unlink.catpipe.net) Received: (from voland@localhost) by unlink.catpipe.net (8.11.3/8.11.3) id f7AAJPl53184 for freebsd-security@FreeBSD.ORG; Fri, 10 Aug 2001 12:19:25 +0200 (CEST) (envelope-from voland) Date: Fri, 10 Aug 2001 12:19:25 +0200 From: Vadim Belman To: freebsd-security@FreeBSD.ORG Subject: Re: distributed natd Message-ID: <20010810121922.E47532@unlink.catpipe.net> Mail-Followup-To: Vadim Belman , freebsd-security@FreeBSD.ORG References: <20010810032158.T3889@gnjilux.cc.fer.hr> <200108100225.MAA23117@tungsten.austclear.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108100225.MAA23117@tungsten.austclear.com.au>; from ahl@austclear.com.au on Fri, Aug 10, 2001 at 12:25:04PM +1000 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 Fri, Aug 10, 2001 at 12:25:04PM +1000, Tony Landells wrote: > > I'm not sure I understood correctly - what are you aiming for? The > > performance increase due to two firewalls simultaneously processing > > traffic or the reduncancy of having one firewall take over if the > > other fails? > > > If it's the latter, I believe there are simpler solutions than > > rewriting natd. > > Mostly the latter, with an additional (side benefit) of the former. > > We have several "long-term" connections for application services > that go through our firewall(s). At the moment if one of the firewalls > went down we'd have a major exercise to change DNS, restart services, > and so on to switch everything across. > > If we were using "virtual" addresses then the switchover would be > more or less transparent. > > However, we don't have a one-to-one mapping between internal addresses > and external addresses, so there is a chance that the mapping one > firewall would choose wouldn't be the same as that chosen by the > second. > > Hence my suggestion. > > The side benefit is that I could then look at, for example, using > dynamic routing to get equal cost paths through each box for load > sharing when they're both up. I would point you to http://www.f5.com. Price might be of some concern here, of course, but BIG-IP is really good solution here. -- /Voland Vadim Belman E-mail: voland@lflat.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 21: 3:21 2001 Delivered-To: freebsd-security@freebsd.org Received: from red.whoowl.com (dsl-65-184-21-205.telocity.com [65.184.21.205]) by hub.freebsd.org (Postfix) with SMTP id 0C2F337B405 for ; Fri, 10 Aug 2001 21:03:18 -0700 (PDT) (envelope-from jvb@whoowl.com) Received: (qmail 21044 invoked by uid 85); 11 Aug 2001 04:03:21 -0000 Received: from jvb@whoowl.com by red.whoowl.com with qmail-scanner-0.96 (hbedv: 6.8.0.0. . Clean. Processed in 1.988532 secs); 11 Aug 2001 04:03:21 -0000 X-Qmail-Scanner-Mail-From: jvb@whoowl.com via red.whoowl.com X-Qmail-Scanner-Rcpt-To: freebsd-security@FreeBSD.ORG X-Qmail-Scanner: 0.96 (No viruses found. Processed in 1.988532 secs) Received: from unknown (HELO black) (192.168.0.107) by 65.184.21.205 with SMTP; 11 Aug 2001 04:03:18 -0000 Message-ID: <004701c1221a$89c57dc0$6b00a8c0@vanbo.whoowl.com> From: "John Van Boxtel" Cc: References: Subject: Re: distributed natd Date: Fri, 10 Aug 2001 21:02:37 -0700 Organization: Whoowl.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 > Not quite, I'm afraid. If a host shuts down it will close open > connections; yet if it dies suddenly (power down, cable cut, etc.) you > will get connection timeout. Unfortunately we should switch gateways ASAP > after failure. Standard TCP timeout seems too long for me. Do you know any > way to shorten this time? Therefore I would rather make gateways "ping" > each other over the link say once a second. There's a technique IRC > servers use to check if client is still alive: once a minute or so they > send the client a "PING" command; if the client does not say "PONG" > without given interval they assume it's dead an shut down the connection. > Something like that could be used here. Of course if TCP connection shuts > down it would also signal that something is wrong. So maybe a persistant TCP connection that sends keep alive type packets. > > This would not be useful for telling if that gateway no longer has > > an upstream connection > If a gateway is alive and looses it's upstream connection and knows it > (interface down, inability to ping next router, etc.) it could detect it > and send the appropriate message to peer gateways. Keeping with the above ping pong idea, maybe instead of icmp packets you can stick with TCP and have the data in the packet have some sort of "upstream ok" / "upstream down" bit in it... > > Interesting stuff :-) > Yeah. I like this subject too. :-) Always fun to think about thinks that have not been tried, of course maybe this all has and we are talking about this thing called the wheel... JVB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Aug 10 21:43:37 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.chem.msu.ru (mail.chem.msu.ru [195.208.208.19]) by hub.freebsd.org (Postfix) with ESMTP id DAE4637B40B; Fri, 10 Aug 2001 21:43:20 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su ([158.250.32.97]) by mail.chem.msu.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NHPRWWM3; Sat, 11 Aug 2001 08:34:33 +0400 Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id f7B4hBu39151; Sat, 11 Aug 2001 08:43:11 +0400 (MSD) (envelope-from yar) Date: Sat, 11 Aug 2001 08:43:10 +0400 From: Yar Tikhiy To: hackers@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: finger/fingerd & home directory permissions Message-ID: <20010811084310.B29956@comp.chem.msu.su> References: <20010809020831.B44660@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010809020831.B44660@comp.chem.msu.su>; from yar@FreeBSD.ORG on Thu, Aug 09, 2001 at 02:08:31AM +0400 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 Thu, Aug 09, 2001 at 02:08:31AM +0400, Yar Tikhiy wrote: > > Currently, finger(1) reveals user information if the user > has created the ``.nofinger'' file, but his home directory > is unreadable for finger(1). > > In the case of local access, it's no problem, since anyone may read > /etc/passwd directly. OTOH, letting remote folks peek at user > information even if the user wants to hide himself is a bad thing. > > The issue I'd like to submit to discussion is what way to choose: > > a) Add a command-line option to finger(1) and fingerd(8) telling > them not to reveal user information if the user's homedir is > protected. > > b) Similar to a), but hide such users by default. > > c) Don't bother at all :-) Thank everyone for your suggestions and comments. I'm going to take the a) way. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Aug 11 1:23:47 2001 Delivered-To: freebsd-security@freebsd.org Received: from ik.ku.lt (ik.ku.lt [193.219.76.193]) by hub.freebsd.org (Postfix) with ESMTP id CC97E37B409 for ; Sat, 11 Aug 2001 01:23:39 -0700 (PDT) (envelope-from garska@ik.ku.lt) Received: from daemon (daemon.ku.lt [193.219.76.199]) by ik.ku.lt (8.11.3/8.11.3) with SMTP id f7B8NK395642 for ; Sat, 11 Aug 2001 10:23:28 +0200 (EET) (envelope-from garska@ik.ku.lt) Message-ID: <001801c1223e$bb83d360$c74cdbc1@ku.lt> Reply-To: "Rolandas Garska" From: "Rolandas Garska" To: Subject: FreeBSD-SA-01:40.fts.asc Date: Sat, 11 Aug 2001 10:22:08 +0200 Organization: Klaipeda University MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C1224F.79F22E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 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 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C1224F.79F22E40 Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: quoted-printable I not find /usr/src/usr.bin/chgrp in source tree on my 4.3-RELEASE. ------=_NextPart_000_0015_01C1224F.79F22E40 Content-Type: text/html; charset="iso-8859-4" Content-Transfer-Encoding: quoted-printable
I not find = /usr/src/usr.bin/chgrp in=20 source tree on my 4.3-RELEASE.
------=_NextPart_000_0015_01C1224F.79F22E40-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Aug 11 2:58:34 2001 Delivered-To: freebsd-security@freebsd.org Received: from thunder.shellsandhosting.com (64.39.176.9.comnet.ca [64.39.176.9]) by hub.freebsd.org (Postfix) with ESMTP id 7294E37B403 for ; Sat, 11 Aug 2001 02:58:30 -0700 (PDT) (envelope-from admin@shellsandhosting.com) Received: from critter (critter [10.0.0.2]) by thunder.shellsandhosting.com (8.11.5/8.11.3) with SMTP id f7A94pY12522 for ; Fri, 10 Aug 2001 09:04:51 GMT (envelope-from admin@shellsandhosting.com) Message-ID: <003901c1219c$ff47e0c0$0200000a@critter> From: "ShellsAndHosting.com Administration" To: Subject: routing Date: Fri, 10 Aug 2001 09:04:31 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C1217B.77DA8C30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C1217B.77DA8C30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I need help on routing. Here is the setup: modem <-> FreeBSD Gateway <-> switch <-> Lan I would like to forward all request from 64.39.183.78 to a lan client = 10.0.0.3 I have tried using -redirect_address 10.0.0.3 64.39.183.78 with natd, = but it won't work. (pehaps the subnet is routed wrong?) Anyway, how can I route 64.39.183.78 to 10.0.0.3 and vice versa? ------=_NextPart_000_0036_01C1217B.77DA8C30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I need help on routing.
Here is the setup:  modem = <-> FreeBSD=20 Gateway <-> switch <-> Lan
I would like to forward all request = from=20 64.39.183.78 to a lan client 10.0.0.3
I have tried using -redirect_address = 10.0.0.3=20 64.39.183.78 with natd, but it won't work. (pehaps the subnet is routed=20 wrong?)
Anyway, how can I route 64.39.183.78 to = 10.0.0.3=20 and vice versa?
 
------=_NextPart_000_0036_01C1217B.77DA8C30-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Aug 11 5:25:35 2001 Delivered-To: freebsd-security@freebsd.org Received: from gnjilux.srk.fer.hr (gnjilux.srk.fer.hr [161.53.70.141]) by hub.freebsd.org (Postfix) with ESMTP id DA5E737B40B for ; Sat, 11 Aug 2001 05:25:31 -0700 (PDT) (envelope-from ike@gnjilux.srk.fer.hr) Received: from gnjilux.srk.fer.hr (ike@localhost [127.0.0.1]) by localhost (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id f7BCPM5J006924 for ; Sat, 11 Aug 2001 14:25:22 +0200 Received: (from ike@localhost) by gnjilux.srk.fer.hr (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) id f7BCPMhf006921 for freebsd-security@freebsd.org; Sat, 11 Aug 2001 14:25:22 +0200 From: Ivan Krstic Date: Sat, 11 Aug 2001 14:25:22 +0200 To: freebsd-security@freebsd.org Subject: Re: distributed natd Message-ID: <20010811142522.Y3889@gnjilux.cc.fer.hr> References: <20010810032158.T3889@gnjilux.cc.fer.hr> <20010810112619.M47149-100000@mail.wlcg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010810112619.M47149-100000@mail.wlcg.com>; from rsimmons@wlcg.com on Fri, Aug 10, 2001 at 11:27:35AM -0400 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 Fri, Aug 10, 2001 at 11:27:35AM -0400, Rob Simmons wrote: > Do share your solution for two firewalls where one will take over if the > other fails. I'm interested. I mostly had hardware solutions in mind. Sites that would need multiple firewalls are very likely to have the resources to buy a hardware solution anyway. An example is the BIG-IP FireGuard: http://www.f5.com/f5products/bigip/fireguard/index.html And I'm sure Cisco has similar solutions as well. As far as software solutions go, I didn't hear of any, but I'm not sure if creating them is really worth the trouble. Then again, I can't say I'm not interested. -- Ivan Krstic - ike " life is the road beneath my feet, love is the girl I wait to meet, and art is everything I create, rob me of any and I will hate, you, my God, my devil, my fate " To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Aug 11 7:38:46 2001 Delivered-To: freebsd-security@freebsd.org Received: from pa169.kurdwanowa.sdi.tpnet.pl (pa169.kurdwanowa.sdi.tpnet.pl [213.77.148.169]) by hub.freebsd.org (Postfix) with ESMTP id 6D6A937B401 for ; Sat, 11 Aug 2001 07:38:40 -0700 (PDT) (envelope-from kzaraska@student.uci.agh.edu.pl) Received: by pa169.kurdwanowa.sdi.tpnet.pl (Postfix, from userid 1001) id A17331C87; Sat, 11 Aug 2001 16:38:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by pa169.kurdwanowa.sdi.tpnet.pl (Postfix) with ESMTP id 5713A5493; Sat, 11 Aug 2001 16:38:23 +0200 (CEST) Date: Sat, 11 Aug 2001 16:38:22 +0200 (CEST) From: Krzysztof Zaraska X-Sender: kzaraska@lhotse.zaraska.dhs.org To: John Van Boxtel Cc: freebsd-security@FreeBSD.ORG Subject: Re: distributed natd In-Reply-To: <004701c1221a$89c57dc0$6b00a8c0@vanbo.whoowl.com> Message-ID: 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 > Keeping with the above ping pong idea, maybe instead of icmp packets you can > stick with TCP and have the data in the packet have some sort of "upstream > ok" / "upstream down" bit in it... By "ping" I did not mean sending ICMP to peer gateway, but sending a special command over this TCP/UDP link between gateways forcing the other end to issue a reply. However it came up to me later, that if we have traffic, then we have state tables updated constantly, thus alive gateway should send the others notifications all the time. So we should try to "ping" it only it case it goes silent (=no update request within given interval) to see if it died or workstation users went home ;) "Upstream up/down" flag is a good idea. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Aug 11 8: 0:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from bilver.wjv.com (dhcp-1-159.n01.orldfl01.us.ra.verio.net [157.238.210.159]) by hub.freebsd.org (Postfix) with ESMTP id 69AA037B407 for ; Sat, 11 Aug 2001 08:00:16 -0700 (PDT) (envelope-from bill@bilver.wjv.com) Received: (from bill@localhost) by bilver.wjv.com (8.11.1/8.11.1) id f7BF0GS49436 for security@FreeBSD.ORG; Sat, 11 Aug 2001 11:00:16 -0400 (EDT) (envelope-from bill) Date: Sat, 11 Aug 2001 11:00:15 -0400 From: Bill Vermillion To: security@FreeBSD.ORG Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... Message-ID: <20010811110015.D49164@wjv.com> Reply-To: bv@wjv.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from owner-freebsd-security-digest@FreeBSD.ORG on Fri, Aug 10, 2001 at 09:03:24PM -0700 Organization: W.J.Vermillion / Orlando - Winter Park 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 > > Date: Fri, 10 Aug 2001 15:55:18 -0400 (EDT) > From: Jim Durham > Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... > > On Thu, 9 Aug 2001, alexus wrote: > > > i'm more or less newbie here > > can you explain me why would you ever want to > > do cvsup+rebuild kernel every friday? what's wrong with your old > > kernel? > The tag "RELENG_4_3" means that cvsup only incorporates security > fixes to the kernel. This is meant for "production servers", where > you want to fool around with things the least amount possible. "If > it ain't broke, don't fix it" . 8-) . > This is about the only way to keep up with security fixes properly. > There's a new exploit happening all the time. > Actually, I watch this list for advisories and then do a cvsup. > I don't do it on a schedule, but others do. > As I said, I'm leery of updating a system running multi-user. > I'm too old for the adrelelin rush Care to say just how old that might be - I'll never see 50 again so I'd like to know what at what age I need to start worrying about this :-) Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Aug 11 17:11:30 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with SMTP id 0D78A37B40B for ; Sat, 11 Aug 2001 17:11:24 -0700 (PDT) (envelope-from karsten@rohrbach.de) Received: (qmail 47614 invoked by uid 1000); 12 Aug 2001 00:11:43 -0000 Date: Sun, 12 Aug 2001 02:11:43 +0200 From: "Karsten W. Rohrbach" To: Tony Landells Cc: freebsd-security@freebsd.org Subject: Re: distributed natd Message-ID: <20010812021143.A47419@mail.webmonster.de> Mail-Followup-To: "Karsten W. Rohrbach" , Tony Landells , freebsd-security@freebsd.org References: <200108100115.LAA20997@tungsten.austclear.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108100115.LAA20997@tungsten.austclear.com.au>; from ahl@austclear.com.au on Fri, Aug 10, 2001 at 11:15:04AM +1000 X-Arbitrary-Number-Of-The-Day: 42 X-URL: http://www.webmonster.de/ X-Disclaimer: My opinions do not necessarily represent those of my employer 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 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable if memory serves me right, there was some loose lobby talk about implementing this in ipfilter at bsdcon last year. i don't remember who was involved, but anyway... /k Tony Landells(ahl@austclear.com.au)@2001.08.10 11:15:04 +0000: > Hi all! >=20 > I've been thinking about ways to improve the robustness of my firewall > and I came up with the following idea, so I thought I'd run it past > some other people for feedback. >=20 > The idea is to run two (or more) firewalls in parallel in such a way > that if one failed the other one would pick up the slack without users > noticing. >=20 > With our current firewall, we generally proxy connections, but for > some things (mostly SSH) we just let it through ipfw, using natd to > translate a "virtual" external address to the internal address of > the target host. >=20 > It occurred to me that if you could make a "distributed" natd, then > you could actually get everyone to use virtual addresses for everything, > and use dynamic routing to control which firewall handles the traffic. >=20 > As far as I can see, the requirements for doing this are: >=20 > a way to restrict the port numbers that natd will use so that > each firewall will have a unique range >=20 > a way for the natd processes on each firewall to tell each other > when they set up or delete a translation >=20 > a way for a starting natd process to obtain a state table from > the natd processes on the other firewall(s) >=20 > a way to tell each natd process what its "peers" are >=20 > Obviously, this wouldn't work terribly well with stateful packet > filtering... >=20 > I haven't even begun to look at the code for natd, but can anyone > see any fatal flaws in the concept? >=20 > Tony > --=20 > Tony Landells > Senior Network Engineer Ph: +61 3 9677 9319 > Australian Clearing Services Pty Ltd Fax: +61 3 9677 9355 > Level 4, Rialto North Tower > 525 Collins Street > Melbourne VIC 3000 > Australia >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message --=20 > Get the all-new Microsoft[tm] IIS (Internet Intrusion Server[tm])! Out no= w! KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n= et/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- catch@spam.de GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B= F46 Please do not remove my address from To: and Cc: fields in mailing lists. 1= 0x --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7dcm/M0BPTilkv0YRAvo1AKC0sMQJCLFiK6yOunivqNmbFdZTwgCbBfZn RIr4+DId3oNBz7wrJWGXn6k= =StA0 -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Aug 11 17:41:59 2001 Delivered-To: freebsd-security@freebsd.org Received: from w2xo.pgh.pa.us (18.gibs5.xdsl.nauticom.net [209.195.184.19]) by hub.freebsd.org (Postfix) with ESMTP id 0B8F637B408 for ; Sat, 11 Aug 2001 17:41:56 -0700 (PDT) (envelope-from durham@w2xo.pgh.pa.us) Received: from jimslaptop.int (jimslaptop.int [192.168.5.8]) by w2xo.pgh.pa.us (8.11.3/8.11.3) with ESMTP id f7C0njm07704; Sat, 11 Aug 2001 20:49:45 -0400 (EDT) (envelope-from durham@w2xo.pgh.pa.us) Date: Sat, 11 Aug 2001 20:42:00 -0400 (EDT) From: Jim Durham X-X-Sender: To: Tim Zingelman Cc: alexus , erb , Josef Karthauser , Nuno Teixeira , Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... In-Reply-To: Message-ID: 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 On Fri, 10 Aug 2001, Tim Zingelman wrote: > On Fri, 10 Aug 2001, Jim Durham wrote: > > > The tag "RELENG_4_3" means that cvsup only incorporates security > > fixes to the kernel. > > This is false. RELENG_4_3 includes critical security fixes in BOTH kernel > and userland. It is NOT always safe to only rebuild your kernel if you > are updating to RELENG_4_3. > > I cite as a reference this message from Kris Kennaway: > > http://groups.yahoo.com/group/freebsd-stable/message/39749 > > - Tim > Yes, sorry, just a typo. Agreed kernel and userland. Just tired I guess. -Jim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message