Date: Thu, 08 Jan 2004 05:47:22 -0800 From: richard childers / kg6hac <fscked@pacbell.net> To: Peter Pentchev <roam@ringlet.net> Cc: freebsd-security@freebsd.org Subject: Re: keystroke logging Message-ID: <3FFD5F6A.4080802@pacbell.net> In-Reply-To: <20040108074450.GD692@straylight.m.ringlet.net> References: <20040107200059.0D9DF16A4D9@hub.freebsd.org> <3FFCD954.4090106@pacbell.net> <20040108074450.GD692@straylight.m.ringlet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I did say 'modified' script(1), yes, the obvious has been taken into account. Thanks for pointing it out, though !! -- richard Peter Pentchev wrote: >On Wed, Jan 07, 2004 at 08:15:16PM -0800, richard childers / kg6hac wrote: > > >>>What do you recommend for keeping track of user >>>activities? For preserving bash histories I followed >>>these recommendations: >>> >>>http://www.defcon1.org/secure-command.html >>> >>> >>> >>Interesting reading but, as others have noted, of limited use. >> >>Keystroke logging can be disabled by - as others have noted - either >>spawning another (perhaps different) shell, using a remote shell ... or, >>for those embarrassing 'oops' moments, `kill -9 $$` works nicely. Try it >>and see. >> >>Daemonized Networking Services has produced a standalone server >>configuration that uses a modified script(1) and .login to collect >>keystroke logs; the target users are consultants, or companies, whom >>administer highly secure networking equipment via serial links or >>command-line interfaces, and whose own business files, or customers - >>banks, say, or government agencies - require logs of what they did - for >>purposes of auditing, disaster recovery, and liability-related issues. >> >>This method captures every keystroke - including typos before hitting >>RETURN - and cannot be sabotaged. As an added advantage, the logs can be >>immediately, or subsequently, forwarded via electronic mail, so that >>they are replicated in multiple places. >> >> > >I hope you've taken into consideration the fact that script(1) by >default does not make any modifications to stdio's standard input/output >buffering. Thus, the script files it creates are fully-buffered by >default, which for normal files means that they are only actually >written to when the buffer fills up, and the buffer is usually 1K to 8K >in size (although I've seen systems with a BUFSIZ of 32K). This means >that if anyone kills the script(1) process before the output has reached >1K (or 4K, or whatever) in size, *no* output will be logged, and even if >the script process is killed afterwards, some of the output will be >lost. Consider: > >[roam@straylight ~]> echo $$ >5781 >[roam@straylight ~]> script outfile >Script started, output file is outfile >Starting interactive C shell >[roam@straylight ~]> echo $$ >5914 >[roam@straylight ~]> ps -o ppid -p $$ > PPID > 5913 >[roam@straylight ~]> kill -HUP 5913Hangup > [roam@straylight ~]> echo $$ >5781 >[roam@straylight ~]> cat outfile >Script started on Thu Jan 8 09:20:17 2004 >[roam@straylight ~]> > >The -t option is of some help, although -t 0 could be implemented a bit >more efficiently with the attached patch. > >G'luck, >Peter > > > -- Richard Childers / Senior Engineer Daemonized Networking Services 945 Taraval Street, #105 San Francisco, CA 94116 USA [011.]1.415.759.5571 https://www.daemonized.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FFD5F6A.4080802>