Re: [tlug] comand-line recording...

[Curt Sampson <cjs@example.com>]

On 2009-09-28 18:32 +0900 (Mon), Bruno Raoult wrote:

> Maybe. But I will not say anything about this... I got their requirements.
> I will surely not ask for more strong rules...

Boy, I'm sure glad you don't work for me!

> > Those accounts [such as "apache"] exist; no person ever logs into
> > them, or is able to log into them. (They have neither password nor
> > ssh access.) Any particular person always logs into a machine using
> > an account dedicated to him only. Anything done as those "role"
> > accounts is done through using sudo to run a command as that user,
> > which is logged.
> 
> So I guess you configure apache with root account... Which is worse
> than anything...

I certainly do not; I use separate role accounts for each application.

Keep in mind that I've been doing Unix- and network-related security as
a professional for about a decade and a half now (including designing
and building an ISP). If you read one of my messages and see something
that is dumb from a security point of view, your first reaction should
be to stop and think, because you've probably misunderstood me.

As for the slightly scornful tone I imagine I perceive in your comment,
keep in mind that it's you, not me, who is breaking one of the primary
and most basic rules of security and auditing: users must never share
authentication information.

> Good point. I totally agree... But Audit will not. They agree we are
> not dealing with malicious
> users. But they want to be sure the log files are untouched... Their
> logic is not mine :-)

Well, so long as they understand that, that's fine. But I do find it
difficult to believe that your audit department is so incompetent that
they would be happy with audit files that can't be trusted, especially
given that you appear to work in the financial industry.

Keep in mind that, in finance, not keeping proper audit records can not
only lose data and money, but can open up your company to legal and
possibly even criminal liability.

> Maybe not: A "grep" will allow to find commands, right?

Perhaps. It depends on what else is in the output. In particular, screen
control codes can mess things up. I just tried script on a session where
I typed "ec^Hcho foo" and, no surprise, the word "echo" does not appear
in the script file.

By the way, there are a lot of things like this that can trip you up.
If you missed this quite obvious one, you're probably missing a lot of
others, too.

> > For configuration files in particular, I suggest keeping them in
> > revision control.
> 
> Yes, except that we are speaking about production system.

Yes, I am suggesting keeping configuration files for production systems
in revision control. I do it all the time.

> For instance: "I cannot send an order to SGX, opening is in 3
> minutes...". In that case we need to check log files, call brokers,
> and make a fast change... We really make the changes directly on
> production systems for this reason.

Right. That in no way precludes using revision control.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com