From owner-freebsd-hackers Tue Feb 11 16:43:53 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B64A37B401 for ; Tue, 11 Feb 2003 16:43:51 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id E23A943FA3 for ; Tue, 11 Feb 2003 16:43:50 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <2003021200434900300duq45e>; Wed, 12 Feb 2003 00:43:49 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA61220; Tue, 11 Feb 2003 16:43:47 -0800 (PST) Date: Tue, 11 Feb 2003 16:43:46 -0800 (PST) From: Julian Elischer To: Wesley Peters Cc: Dag-Erling Smorgrav , hackers@freebsd.org Subject: Re: Some "security" questions. In-Reply-To: <200302111532.28994.wes@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Feb 2003, Wesley Peters wrote: > On Monday 10 February 2003 23:59, Dag-Erling Smorgrav wrote: > > Did we somehow break acct(2), or is that somehow inadequate to the task? It > should be ideal for what Julian's customer wants, I would think. See also > acct(5), sa(8) and accton(8). Acct doesn't give the arguments of the commands rexec (as pointed out earlier in this thread) does exactly what I want. e.g. (sorry about the linewrap) Feb 11 16:15:00 julian /kernel: restricted execve [init] Feb 11 16:15:00 julian /kernel: $Id: rexec.c,v 1.2 2002/08/26 13:20:05 dawidek Exp $ Feb 11 16:15:31 julian /kernel: rexec: [/usr/bin/tail] tail -f /var/log/messages (called by csh [95318]) (uid=0, gid=0, euid=0, egid=0) Feb 11 16:15:58 julian /kernel: rexec: [/bin/ls] ls -laR /usr/local/bin /usr/local/lib (called by tcsh [95319]) (uid=1000, gid=1000, euid=1000, egid=1000) Feb 11 16:16:09 julian /kernel: rexec: [/usr/bin/vi] vi /etc/passwd (called by tcsh [95320]) (uid=1000, gid=1000, euid=1000, egid=1000) Feb 11 16:16:48 julian /kernel: rexec: [/usr/bin/su] su (called by tcsh [95321]) (uid=1000, gid=1000, euid=1000, egid=1000) Feb 11 16:16:50 julian su: julian to root on /dev/ttyp9 Feb 11 16:16:50 julian /kernel: rexec: [/bin/csh] _su (called by su [95321]) (uid=0, gid=0, euid=0, egid=0) Feb 11 16:16:50 julian /kernel: rexec: [/bin/hostname] hostname -s (called by csh [95322]) (uid=0, gid=0, euid=0, egid=0) Feb 11 16:16:59 julian /kernel: rexec: [/sbin/kldunload] kldunload rexec (called by csh [95323]) (uid=0, gid=0, euid=0, egid=0) Feb 11 16:16:59 julian /kernel: restricted execve [unload] > > > > 2/ they want to disable a login if it fails 'n' sequential logins > > > anywhere in the system. i.e. 2 on one machine followed by another on > > > another machine. > > > > "Yes we can do that" with a smart PAM module. > > VAX/VMS had something known as 'breakin evasion mode' on terminal devices: > if more than X login attempts were noted in Y seconds, the system would > delay an ever-increasing amount of time before it would issue the next > login prompt. I vaguely remember encountering this on a unix system too.. what they want though is the same thing, over a whole network of machines.. i.e teh 'N' login attempts don;t have to be on the same machine for the patern to be noticed. We have this here using RSA "ACE" tokens, but we needn't go so far as that.. a radius server could keep track of successes and failures.. and pam_radius could hook it into all teh apps. > > It would be straightforward to implement this on any authentication server, > simply note the 'breakin attempt' and slow responses to the being attacked. > I've not looked at any such servers for many years, but Radius certainly > seemed simple enough to do this quickly in 1998. yes. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message