| JP Vossen on 1 Sep 2007 18:56:39 -0000 |
|
Date: Sat, 1 Sep 2007 06:58:49 -0400 From: "K.S. Bhaskar" <bhaskar@bhaskars.com> Subject: Re: [PLUG] shell script help... > <snip> > Also http://seclists.org/pen-test/2005/Jul/0073.html gives a FOSS way to implement keystroke logging, at least for shells. I'd not see that, interesting. Parsing the output back into something usable look to be a bit ugly though. That link also reminded me of 'screen' and its ability to log sessions. The suggestions above wrt using 'script' or a shell script using 'script' as a default shell are interesting. 'screen' can do the same thing. I covered both of these in a slightly different context in the _bash Cookbook_ recipe 17.6 "Logging an entire Session or Batch Job." Note this was intended for logging output, not as any kind of user auditing or security mechanism. The thing that bugged me about the 'script' command is that I was unable to find a way to run a script inside 'script.' (The name also bugs me since it's obviously a bit tricky to talk about.) Once you run 'script' to generate a "typescript" you are sitting in a new shell and at a command prompt. I had a need to log a long section of output within an even longer session. So I had to turn on logging at some point, run stuff, then turn it off. I couldn't find a way to do that with script. But I was able to do with using 'screen'. From outside screen to grab *everything*: screen -L /path/to/logfile From inside screen (already running): # Set a log file and turn on logging screen -X logfile /path/to/logfile && screen -X log on # your commands here # Turn logging back off screen -X log off As noted 'screen' has other advantages such as being able to reconnect to it after a network glitch (recipe 17.4) or being able to share a session for t-shooting or training (17.5). I love 'screen.' I'd *guess* could could configure each user with a .screenrc file that they can't edit, that configures things as you want them, including logging, then set screen as their default shell. I'm not sure I think that's a great idea, but... The problem I see using either 'script' or 'screen' in this way is that you get *everything*. You get input, output, control characters from editing sessions, the works. So it gets big, and ugly. Fast. A denial of service attack is trivial, and if I was up to something, I'd generate a ton of noise and try to hide what I was doing in that. That's probably even easier in 'screen' as you could start up 3 or 4 windows running 'ls' commands and catting /dev/random, then sneak commands in. I'd guess all the output would get all mangled in the log, though to be honest I haven't looked into how 'screen' might handle that.
http://en.wikipedia.org/wiki/GNU_Screen Wikipedia on GNU screen http://www.kuro5hin.org/story/2004/3/9/16838/14935 GNU Screen: an introduction and beginner's tutorial http://www4.informatik.uni-erlangen.de/~jnweiger/screen-faq.html (unofficial) GNU screen FAQ http://www.delorie.com/gnu/docs/screen/screen_toc.html GNU screen docs http://unix.derkeiler.com/Newsgroups/comp.unix.shell/2004-04/0294.html Using gnu screen as default login shell (as that helpful) Later,
JP
----------------------------|:::======|-------------------------------
JP Vossen, CISSP |:::======| jp{at}jpsdomain{dot}org
My Account, My Opinions |=========| http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
Microsoft has single-handedly nullified Moore's Law.
Innate design flaws of Windows make a personal firewall, anti-virus
and anti-malware software mandatory. The resulting software arms race
has effectively flattened Moore's Law on hardware running Windows.
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|