Re: keystroke logging

From: Peter Pentchev (roam_at_ringlet.net)
Date: 01/08/04

  • Next message: Dag-Erling Smørgrav: "Re: HEADS UP: OpenSSH 3.7.1p2"
    Date: Thu, 8 Jan 2004 09:44:50 +0200
    To: richard childers / kg6hac <fscked@pacbell.net>
    
    
    

    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

    -- 
    Peter Pentchev	roam@ringlet.net    roam@sbnd.net    roam@FreeBSD.org
    PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
    Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
    This sentence is false.
    Index: src/usr.bin/script/script.c
    ===================================================================
    RCS file: /home/ncvs/src/usr.bin/script/script.c,v
    retrieving revision 1.20
    diff -u -r1.20 script.c
    --- src/usr.bin/script/script.c	4 Sep 2002 23:29:06 -0000	1.20
    +++ src/usr.bin/script/script.c	8 Jan 2004 07:39:00 -0000
    @@ -150,10 +150,12 @@
     	if (child == 0)
     		doshell(argv);
     
    -	if (flushtime > 0)
    +	if (flushtime > 0) {
     		tvp = &tv;
    -	else
    +	} else {
    +		setvbuf(fscript, NULL, _IONBF, 0);
     		tvp = NULL;
    +	}
     
     	start = time(0);
     	FD_ZERO(&rfd);
    @@ -187,7 +189,7 @@
     			(void)fwrite(obuf, 1, cc, fscript);
     		}
     		tvec = time(0);
    -		if (tvec - start >= flushtime) {
    +		if (flushtime > 0 && tvec - start >= flushtime) {
     			fflush(fscript);
     			start = tvec;
     		}
    
    



  • Next message: Dag-Erling Smørgrav: "Re: HEADS UP: OpenSSH 3.7.1p2"

    Relevant Pages

    • Re: Creating script support for console application
      ... After mapping the file into memory, you may want to allocate a new buffer ... Of course, a decent script will keep track of line-numbers, so syntax errors ... > commands that tell the program where to BREAK, LOOP, START. ... > thinking of putting each line in an element of an array. ...
      (microsoft.public.vc.language)
    • pyodbc.Error Crash
      ... I believe this bug is also related to the other problem I just reported. ... DB = Microsoft Access XP ... # or buffer length ') ... The broke.py script has 4 select statements but only one is executed. ...
      (comp.lang.python)
    • Re: Numeric or character ?
      ... > anno4000@xxxxxxxxxxxxxxxxxxxxxxx (Anno Siegel) wrote: ... >> when the script happens to do mass IO via STDOUT. ... the buffer just doesn't fill up so much. ... "Reply" at the bottom of the article headers. ...
      (comp.lang.perl.misc)
    • Re: .Net Equivilant for sqlcmd or osql
      ... applications like SQL Management Studio work. ... Also, you do not have to strip the comments, it works just fine, ... Read EACH line into a string buffer. ... Read your script file and split it on the GO ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: A couple of SED questions
      ... with the shell script, not the sed script. ... There is a buffer - I think it is called the hold buffer - accessed with G, H, X and other commands. ... You may be using a version of sed which views end of line as the third s command delimiter. ...
      (comp.unix.shell)