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/