This may be beating a dead horse and may not be what you're looking for,
but I got some information today you may want.
On 03/28/2008 09:48 PM, Kenny Lussier wrote:
All,
I am looking for a way to record terminal sessions on Linux systems
(usually people logging into boxes via ssh).
From: Paul Lussier
Not knowing the letter of the standard, or the standard for that
matter, I can not speak definitively on the matter.
It's OK - nobody really does except the people who want $300/hr to
give you evasive answers on the matters.
This may or may not suffice for the current
On Apr 2, 2008, at 12:15, Kenny Lussier wrote:
We are
dealing with PCI (Payment Card Industry) compliance.
Just one of the reasons this is such a braindead standard - there's a
requirement for tamper-proof logs (at least in the last version I did
an audit for).
I attempted to get the
On Thu, Apr 3, 2008 at 12:10 PM, Bill McGonigle [EMAIL PROTECTED] wrote:
http://blog.bfccomputing.com/articles/2008/03/18/eliminating-credit-card-fraud
From the above: PCI ... can never be perfect, no matter how hard
everybody tries.
A'yup. Say it with me now: Security is a process, not a
Bill McGonigle [EMAIL PROTECTED] writes:
I don't think there's a linux way to do tamper-proof logs that meets
the letter of the standard.
Not knowing the letter of the standard, or the standard for that
matter, I can not speak definitively on the matter.
However, you could have anything that
Mark Greene [EMAIL PROTECTED] writes:
Hello,
My name is mark and I'm new to the list.
Hello Mark, welcome :)
EMC has most definitely not discontinued the Centera product line. The
first generation models are EOL'd for 2009, but the lastest (4th) gen is
actively being sold and has no EOL
Many of the suggestions made so far seem to assume that the
users are cooperative and will not try to defeat any of the
suggested auditing mechanisms. Is that assumption correct?
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
Kenny Lussier [EMAIL PROTECTED] writes:
The point isn't to limit what they can do on the system (that is a
completely different issue). The problem is to account for what they
do, and to go to the logs and say that User X issued command Y at n
time. The truth is, we don't care what shell they
On Wed, Apr 2, 2008 at 10:27 AM, Michael ODonnell
[EMAIL PROTECTED] wrote:
Many of the suggestions made so far seem to assume that the
users are cooperative and will not try to defeat any of the
suggested auditing mechanisms. Is that assumption correct?
That is a safe assumption. The
Many of the suggestions made so far seem to assume that the users
are cooperative and will not try to defeat any of the suggested
auditing mechanisms. Is that assumption correct?
That is a safe assumption. The users are the ones that have asked
for better monitoring then what is done
On Wed, Apr 2, 2008 at 11:32 AM, Michael ODonnell
[EMAIL PROTECTED] wrote:
Many of the suggestions made so far seem to assume that the users
are cooperative and will not try to defeat any of the suggested
auditing mechanisms. Is that assumption correct?
That is a safe assumption.
On Wed, Apr 2, 2008 at 10:15 AM, Paul Lussier [EMAIL PROTECTED] wrote:
Kenny Lussier [EMAIL PROTECTED] writes:
The point isn't to limit what they can do on the system (that is a
completely different issue). The problem is to account for what they
do, and to go to the logs and say that
On Wed, Apr 2, 2008 at 9:57 AM, Paul Lussier [EMAIL PROTECTED] wrote:
Kenny Lussier [EMAIL PROTECTED] writes:
Unfortunately, is isn't 100% reliable. As you pointed out, there are
a lot of ways around these things, such as executing a script that
executes a bunch of commands. The only
Kenny Lussier [EMAIL PROTECTED] writes:
I may have over-simplified the situation in that statement. We are
dealing with PCI (Payment Card Industry) compliance.
Ha ha ha ha! Stop it, you're killing me!
Hannaford was PCI Compliant too. You might as well say your
striving for Los Alamos level
Kenny Lussier [EMAIL PROTECTED] writes:
However, I agree that controlling as much of the environment as
possible is the road to go down.
Well, you do have the choice to take The Road Less Traveled, in which
case, you want the *other* one! :)
--
Seeya,
Paul
On Wed, Apr 2, 2008 at 1:56 PM, Paul Lussier [EMAIL PROTECTED] wrote:
Kenny Lussier [EMAIL PROTECTED] writes:
I may have over-simplified the situation in that statement. We are
dealing with PCI (Payment Card Industry) compliance.
Ha ha ha ha! Stop it, you're killing me!
Hannaford
On Mon, March 31, 2008 9:34 pm, Kenny Lussier said:
It also has me thinking about different ways of manipulating the
command prompt to add unique identifiers. I might cobble all f this
together and make something useful after all! :-)
Here's how I've been setting mine:
Ben Scott [EMAIL PROTECTED] writes:
Practical guidance on how to *actually secure* systems is sadly less
available than bureaucracy.
Well that makes sense, given that bureaucracy is developed and written
by bureaucrats which comprise the agencies publishing this stuff.
Bureaucracies consist
On Mon, Mar 31, 2008 at 12:46 AM, [EMAIL PROTECTED] wrote:
Date: Sun, 30 Mar 2008 20:24:10 -0400
From: Kenny Lussier [EMAIL PROTECTED]
The more I look into this, the more I am realizing that I will need to
do more then just one thing. I will need to do something at either the
On Mon, Mar 31, 2008 at 7:59 AM, Thomas Charron [EMAIL PROTECTED] wrote:
But you'll have to make sure you only have one. Some scripts may
call /usr/bin/bash, others, /usr/bin/sh, others, /usr/bin/ksh, etc..
Yes, we already do that. All shells are currently symlinks to /bin/bash.
Thanks,
On Mon, Mar 31, 2008 at 12:00 PM, Bill McGonigle [EMAIL PROTECTED] wrote:
I ran into this a while back when I was trying to come up with a billing
system that would track my ssh sessions and didn't find a satisfying answer.
script or sudosh would seem to fit the bill, there. Ken seems to
Kenny Lussier [EMAIL PROTECTED] writes:
The control characters aren't the only reason that script doesn't work
for us. Script will write out to a file, but the lines aren't time
stamped, so it's impossible to know when a command was run. Also, the
file would need to be writable by the user,
On Mon, Mar 31, 2008 at 1:03 PM, Paul Lussier [EMAIL PROTECTED] wrote:
Kenny Lussier [EMAIL PROTECTED] writes:
The control characters aren't the only reason that script doesn't work
for us. Script will write out to a file, but the lines aren't time
stamped, so it's impossible to know when
On Mon, Mar 31, 2008 at 2:43 PM, Ben Scott [EMAIL PROTECTED] wrote:
On Mon, Mar 31, 2008 at 1:16 PM, Tom Buskey [EMAIL PROTECTED] wrote:
I concluded it was lots of work to provide security that was not auditable.
Trying to achive a secure audit trail using the usual Unix shells is
(IMO)
On Mon, Mar 31, 2008 at 1:03 PM, Paul Lussier [EMAIL PROTECTED] wrote:
Kenny Lussier [EMAIL PROTECTED] writes:
The control characters aren't the only reason that script doesn't work
for us. Script will write out to a file, but the lines aren't time
stamped, so it's impossible to know
On Mon, Mar 31, 2008 at 12:52 PM, Paul Lussier [EMAIL PROTECTED] wrote:
Bill McGonigle [EMAIL PROTECTED] writes:
I see you've already found lastcomm and friends, but it would be great
to know what you come up with for a correlation mechanism.
Can't you log everything possible via
Kenny Lussier wrote:
This is exactly the case. We have already limited what people can do
on these systems using standard permissions, sudo, etc. What we need
now is to log everything that is done so that when the systems are
audited, we can provide the details of what has been done on the
On Mon, Mar 31, 2008 at 3:09 PM, Kenny Lussier [EMAIL PROTECTED] wrote:
As you pointed out, there are a lot of ways
around these things, such as executing a script that executes a bunch
of commands.
Also in that vein: Programs like vim or emacs, which allow one
execute arbitrary commands
On Mon, Mar 31, 2008 at 3:35 PM, Dan Coutu [EMAIL PROTECTED] wrote:
Sounds to me like you need the kind of security auditing that is found
in DoD administered machines.
Also banks, insurance companies, and other financial institutions,
hospitals and other health-care institutions,
On Mon, Mar 31, 2008 at 3:35 PM, Dan Coutu [EMAIL PROTECTED] wrote:
Kenny Lussier wrote:
This is exactly the case. We have already limited what people can do
on these systems using standard permissions, sudo, etc. What we need
now is to log everything that is done so that when the systems
On 3/31/08, Tom Buskey [EMAIL PROTECTED] wrote:
On Mon, Mar 31, 2008 at 3:50 PM, Ben Scott [EMAIL PROTECTED] wrote:
On Mon, Mar 31, 2008 at 3:35 PM, Dan Coutu [EMAIL PROTECTED] wrote:
Sounds to me like you need the kind of security auditing that is found
in DoD administered
Date: Mon, 31 Mar 2008 13:16:57 -0400
From: Tom Buskey [EMAIL PROTECTED]
Cc: Greater NH Linux User Group gnhlug-discuss@mail.gnhlug.org
Bash has a -r mode for Restricted Shell as well. It's in the manpage at
least.
You might consider bash -r in conjunction with $HISTTIMEFORMAT and
On Mon, Mar 31, 2008 at 4:21 PM, Chris [EMAIL PROTECTED] wrote:
What about Secure Solaris I believe it logs everything by
default, and there is no such thing as root. (Not sure how that
works but)
I think it was folded into Solaris 10.
Solaris has RBAC which can be setup
Date: Sat, 29 Mar 2008 13:13:43 -0400
From: Kenny Lussier [EMAIL PROTECTED]
Using script isn't an option because it logs all of the control
characters.
Not sure why you object to control characters since they're
legitimately part of most sessions.
They are legitimate, but
From: Paul Lussier [EMAIL PROTECTED]
Date: Mon, 31 Mar 2008 12:03:21 -0500
Cc: Greater NH Linux User Group gnhlug-discuss@mail.gnhlug.org
file would need to be writable by the user, which defeats the point of
all the logging :-)
Wow, the lack of creativity here is astounding! :)
On Mon, Mar 31, 2008 at 5:36 PM, [EMAIL PROTECTED] wrote:
From: Paul Lussier [EMAIL PROTECTED]
Date: Mon, 31 Mar 2008 12:03:21 -0500
Cc: Greater NH Linux User Group gnhlug-discuss@mail.gnhlug.org
file would need to be writable by the user, which defeats the point of
all the
On Mon, Mar 31, 2008 at 4:12 PM, Tom Buskey [EMAIL PROTECTED] wrote:
These days, it's the Common Criteria standards,
NISPOM and Chapter 8 specifically.
NISPOM Chapter 8 is even less useful than the CC stuff. NISPOM
doesn't even define terms in many cases. And it never covers
implementations
On Mon, March 31, 2008 5:36 pm, [EMAIL PROTECTED] said:
...
export PS1='[ `date` ]'
...
Note: That will probably not do what you intended... Each time a
prompt is issued, the same exact prompt will be issued, namely
[ Mon Mar 31 17:32:54 UTC 2008]. date will not be rerun
before each
Date: Mon, 31 Mar 2008 17:59:11 -0400 (EDT)
From: John Abreau [EMAIL PROTECTED]
Cc: gnhlug-discuss@mail.gnhlug.org
...
export PS1='[ `date` ]'
...
Note: That will probably not do what you intended... Each time a
prompt is issued, the same exact prompt will be issued, namely
[
On Sat, Mar 29, 2008 at 8:51 AM, Kenny Lussier [EMAIL PROTECTED] wrote:
The control characters aren't the only reason that script doesn't work
for us. Script will write out to a file, but the lines aren't time
stamped, so it's impossible to know when a command was run. Also, the
file would
On Fri, Mar 28, 2008 at 11:19 PM, Ben Scott [EMAIL PROTECTED] wrote:
On Fri, Mar 28, 2008 at 9:48 PM, Kenny Lussier [EMAIL PROTECTED] wrote:
Using script isn't an option because it logs all of the control characters
...
Why not just filter out the control characters after the fact, with
On Sat, Mar 29, 2008 at 8:51 AM, Kenny Lussier [EMAIL PROTECTED] wrote:
The control characters aren't the only reason that script doesn't work
for us. Script will write out to a file, but the lines aren't time
stamped, so it's impossible to know when a command was run. Also, the
file would
I need to log everything from the time a user logs in to the time
they log out, including all commands, output of commands, etc.
ttysnoop appears to be close to what you want, though straight
out of the box it looks like it's not configured to relay
session automatically.
Using script isn't
On Sat, Mar 29, 2008 at 10:40 AM, Michael ODonnell
[EMAIL PROTECTED] wrote:
Using script isn't an option because it logs all of the control
characters.
Not sure why you object to control characters since they're
legitimately part of most sessions.
They are legitimate, but they are
On Sat, Mar 29, 2008 at 9:09 AM, Thomas Charron [EMAIL PROTECTED] wrote:
If you want to log what a script does, your talking about needing a
modified version of every single shell, or only having one on the
system. Scripts are run in a subshell much of the time.
That's why I am looking
Date: Sat, 29 Mar 2008 08:51:00 -0400
From: Kenny Lussier [EMAIL PROTECTED]
doesn't record the output, though. The other problem is scripts.
Someone can copy a script to a box and run it, and the only thing that
is logged is the executed script name, not what was actually done...
Wrapping
All,
I am looking for a way to record terminal sessions on Linux systems
(usually people logging into boxes via ssh). Basically, I need to log
everything from the time a user logs in to the time they log out,
including all commands, output of commands, etc. The output isn't
essential, but it
On Fri, Mar 28, 2008 at 9:48 PM, Kenny Lussier [EMAIL PROTECTED] wrote:
Using script isn't an option because it logs all of the control characters ...
Why not just filter out the control characters after the fact, with
Perl or sed or whatever? I've done something like that in the past.
The
48 matches
Mail list logo
