Re: Fw: OT - Getting fired for database oops

Tanel Poder wrote,on my timestamp of 27/05/2009 10:28 PM:

Well the root ownership doesn't prevent you from renaming the original
sqlplus/admin directory to something else and cloning that directory back
using cp -rp, which would lose the root ownership bit.

If you set the whole tree as owned by root - then you can just clone your
whole directory to /tmp and run from there.

Also there are other tricks like using LD_PRELOAD env variable to redirect
some file opens to your custom files without the application knowing about
it. 
So the setting the root ownership wouldn't be a secure solution, it would be
"security by obscurity" at most.



This works more from the point of view of not having to check
that original files got changed.  Which is a tricky proposition
at best: how often should one check and for how long?

I do recall we checked our externalized servers every hour and
even then that didn't stop crackers from planting a root kit
every week or so. And this was on hardened Linux servers, not
vanilla installs.

Every time we got one, we quarantined the server to try and find
out how they got in. Then we added the corresponding improvement
to our "clone base" from which we rebuilt the server before
putting it out there again.  And we had other tricks up
our sleeves as well.

Of all approaches, the one that worked best was the "bait
server" approach: have a sacrificial "easy" server, so
baddies would concentrate on the "easiest" thing
first.  They are not stupid: given the option between an
easy break-in and a hard one, they take the easy path
every time.  But that was when cracking was done by
humans. Nowadays there are a lot of programs that do
the same systematically, at CPU speed...

I'm not suggesting these approaches for db servers: ours
were not such, either. Besides, I see little reason for db
servers to be out there in the open net: they should always
be "behind bars", with well defined and recognized "doors".

But the real cure is to close off the "default" loopholes:
take away the public privileges from any routines that
might bypass the db environment and go to the OS.
As well as lock down well known holes like SMTP and such.
Old login ids.  Old packages not used anymore. And so on.

It's a never ending battle.  I doubt applying regular
"security patches" is the solution either, although it
helps.  These things obey basic principles.  Concentrate on
getting those right rather than "fixing the symptom", is I
think a better approach?



--
Cheers
Nuno Souto
in rainy Sydney, Australia
dbvision@xxxxxxxxxxxx
--
http://www.freelists.org/webpage/oracle-l

Other related posts: