John H. Robinson, IV wrote:
Nice, in theory. Those pesky 0-day volnerabilites, along with the path leackages make this a poor idea. However, a lot of sites do exactly that because of the tradeoff between security and convenience.
A lot of sites do exactly that because the tradeoff between security and convenience makes it nice in practice also!
https: An email goes out to the admin group stating that the https dd not start, and needs to be started manually. That works. good enough. At least for ACS at UCSD.
That doesn't work for us, didn't work for MP3.com, and doesn't work for hardly any of the ecommerce sites on the web because for each second we have to wait for one of the admins to get the mail and get to a computer (which could be hours since this sort of thing tends to happen at night for some reason) we are losing money. Break-ins are pretty rare for reasonably admin'd Linux boxes. Break-ins of webservers with SSL on them even more rare. Break-ins of webservers with SSL on them where someone went looking for the key with the intention of setting up a spoofed site... Let's talk about some of the REAL threats we face:
1. Password guessing. We get lots of attempts at automated password guesses. If we let someone with a shell account on a public facing box use a trivial password (such as their username) and they have a common username, they are toast. I saw this happen once on a machine a year or two ago. For this reason we have as few shell accounts as possible facing the outside world.
2. Poorly written web apps. The last break-in I saw used a PHP bulletin board/online chat sort of app on an isolated box because they knew that app was suspicious but someone insisted it be run anyway. It got hacked and we took the app down and now that the point is proven it hasn't gone back up since.
3. ssh/httpd/whatever buffer overflow. Hasn't happened in quite a while though as awareness of buffer overflows has been greatly increased in recent years.
The likelyhood of any one of these things are so much greater than the likelyhood of someone swiping our SSL key or happening across a password that got swapped out on a disk that left our offices that they are the sorts of things we concentrate on. If it is easy to mitigate the risk due to a swiped SSL key or swapped out password I do it but leaving the site down for extended periods of time or having to build a special install of our OS which implements swap encryption just isn't worth it in practice.
In your MySQL application, liberal use of AES_ENCRYPT and EAS_DECRYPT would do wonders for protecting sensitive data.
I don't think mysql 4.1.20 has AES_ENCRYPT etc. But if we can ever make the jump to mysql5 we will look into it. We currently use a sort of helper program to encrypt the data.
Users of FreeBSD have enjoyed, for years, enjoyed the benafts of an encrypted swap (while swap does not get backup up to tape, it does exst on the spining disks that go missing[1])
I'm pretty sure Linux has had this for years also. Just make an encrypted device and point swap at it.
Are these practical, and good enough for you? Or do you need more? If you need ideas for a specific example, I would be happy to brainstorm with you. If you are just trying to play Stump the Chump, find another chump.
Not all of them are practical and good enough. A mysql version migration can be a major undertaking. Not gonna happen overnight. Encrypted swap doesn't really buy us much as far as security goes as a number of other things could. And as I mentioned above encrypting the SSL key isn't practical for us.
As a sysadmin/technology person I am really trying to get out of the habit of saying "ALL you have to do is..." and trivializing other peoples technical issues.
-- Tracy R Reed http://ultraviolet.org A: Because we read from top to bottom, left to right Q: Why should I start my reply below the quoted text -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
