On Thu, 2006-06-15 at 20:52 +0200, Marc Dirix wrote:
> >
> >
> >> 6) Always maintain a good back-up regimen for your database.
> >
> > I think asking users to solve security issues by having "good backups"
> > is really ridiculous.
> >
>
> As most of us understood, he meant server-side backup of the
> database, so if something does
> go wrong, the admin can restore the pre-security breach situation.
I hope that he meant that. Otherwise what I said would be off topic.
> > Besides the fact that most people don't have good backups (even those
> > that think they do- when was the last time you unspooled all of your
> > backups to make sure they contained what you think they contain?)-
> >
>
> You are probably talking about your own database system. I don't use
> tapes, and or
> compression, in order to verify my backup integrity directly.
The PostgreSQL people over at about oh-say 7.1 had a problem. Their
backup tool could produce _bad_ backup files. The program would
complete, exit 0 and everything, but the backup file couldn't be loaded.
A few hours with awk and sed, it was all straightened out, but it would
seem that I ran for about 6-7 months without a good backup.
Now, _I_ didn't check my backups except once-maybe twice- after I set up
the cron job in the beginning (a few years ago, I suppose). Somewhere
along the line, the database got some data that the backup tool couldn't
deal with.
Does your backup system protect against this failure?
One day, I took over for a customer who's previous admins had thought
rsync was a good way to backup their mysql database. One day they came
in and all the databases were empty. Can you guess why?
Does your backup system protect against this failure?
At another client, they use Raiser's Edge- and their administrators take
backups by shutting down the MS-SQL database, dumping, and reloading.
One long weekend, everyone in the overseas office was locked out of the
application because it failed to restart the database engine.
Does your backup system protect against this failure?
A friend of mine thought they no longer needed tar or mysqldump to take
backups, but instead set up MySQL to do that fancy new replication
thing, and one day accidentally sent a misplaced DELETE instruction.
Does your backup system protect against this failure?
> > what's to say that once restored, the host isn't compromised again and
> > this time- even worse?
> >
>
> It goes without saying that after a breach, the hole must be plunged
> before restoring the database, but wouldn't you be glad to say to
> your users, it will take a few days, but your old mails are save,
> instead of, it will take a few days, *and* all your emails are gone?
No, apparently, it doesn't go without saying:
Go back and look at the parent- this was about security problems, and
not about breaches.
> I think the recommendations where good for the average system.
Check again: did I say that they weren't good advice?
> > What happens when the invaders manage to lie hidden for a long
> > time- are
> > you really going to roll your email back six months because that's the
> > last time you _know_ your data was safe?
> >
>
> It is a recommendation, as with all things, you can't do anything
> better than your best.
No kidding.
> If a hacker has taken up the task to destruct your database
> thouroughly, than your sour, but at least you as system
> *administrator* gave your best shot.
The administrator that you're talking about obviously equates security
with lack-of-breaches. That's not what we're talking about.
We're talking about security as in the kind that the rest of the world
uses- as in demonstrating risk, privilege possibility, attack vectors,
and knowledge of how DBMail interacts with the system, the users, and
the environment.
These things are quite a bit more complicated than whether DBMail can
run as root or not.
If a security advisory says:
"Make sure all services that aren't used are turned off"
Are you going to tell me that this has been helpful to you?
How about to someone who doesn't know what that means?
On the other hand, if a security advisory says:
"Authorized users could denial of service other users on your DBMail
installation. Make sure you configure your SQL server for auditing and
take appropriate action against those users. Clustering can minimize
this."
Wouldn't you say that you were at least told something you might not
know?
The problem with this statement is that I don't know if it's true.
Nobody does. So we can't say it. It's not really helpful--- yet.
The environment that I'm running DBMail in is completely _free_ from
security vulnerability. The users cannot deny services to eachother, and
so on. But this doesn't mean that DBMail is secure- only that I chose to
avoid the issue.
I'd like to recommend that we _not_ avoid the issue. Not because _I_
need DBMail to be secure- as I said, I'm already fine- it's the rest of
you I'm worried about: The ones that think security breaches are what
you've got to worry about.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
