Date: Tue, 11 Feb 2003 15:32:28 -0800 From: Wesley Peters <wes@softweyr.com> To: Dag-Erling Smorgrav <des@ofug.org>, Julian Elischer <julian@elischer.org> Cc: hackers@freebsd.org Subject: Re: Some "security" questions. Message-ID: <200302111532.28994.wes@softweyr.com> In-Reply-To: <xzp65rrmemi.fsf@flood.ping.uio.no> References: <Pine.BSF.4.21.0302101752500.49102-100000@InterJet.elischer.org> <xzp65rrmemi.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 10 February 2003 23:59, Dag-Erling Smorgrav wrote:
> Julian Elischer <julian@elischer.org> writes:
> > 1/ Command logging. We're thinking that a hacked version of the shell
> > that logs commands may do what they want, but personally I
> > think that if you are going to log things then you really want to
> > PROPERLY do it, and log the EXEC commands along with the arguments.
> > (sadmin et al. doesn't give arguments, and neither does ktrace)
>
> "Yes, we can do that" in the sense that it can be implemented if
> there's a demand for it, but I don't think any existing code can do
> it.
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).
> > 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.
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.
> > I can immagine using pam_radius, and hacking a radius server
> > to track login fails.. Anyone have any better ideas?
> > Maybe a pam_module specially written? (hmmmm)
>
> PAM has a mechanism which allows for arbitrary named objects to be
> stored for the duration of a PAM transaction, along with a destructor
> which is called when the object is released (either explicitly or when
> the transaction ends). You could write a PAM module which stores an
> object in the authenticate phase, then modifies its contents in the
> setcred phase (which only occurs if authentication was successful).
> The destructor would register success or failure in a database
> depending on whether the object was modified before release. The
> exact nature of that database is not important.
It would be great to see a PAM implementation, then the server wouldn't
matter. On the other hand, doing it at the server level would mean it's
implemented on EVERYTHING, even network equipment with user accounts. The
trick will be deciding which SNMP MIBs to control X, Y, and Z. Augh!
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302111532.28994.wes>