Tracy R Reed wrote: > John H. Robinson, IV wrote: > > >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
You asked for Real Life example. I gave you one. It is also Good Enough. Not my fault that your load balancers can't redirect traffic away from a downed https host. > Break-ins are pretty rare for reasonably admin'd Linux boxes. > Break-ins of webservers with SSL on them even more rare. I think we both know that https s nothing magical, so saying that https somehow adds a layer of protection to the *server* is misdirection at best. SSL protects the data in transit, nothing else. Now, if your server offered *only* https (and not even ssh) *AND* the https was set up to check client certificates (nothing that any general publuc e-commerce site would ever do) and limited communication to only known clients, then yes. I would accept the argument that https is more secure (server speaking) than http. I don't think you can name one site that actually checks client certificats on their https. > Let's talk about some of the REAL threats we face: > > 1. Password guessing. Encryption of data tapes won't to a thing about this. > 2. Poorly written web apps. Ibid. > 3. ssh/httpd/whatever buffer overflow. Ibid. Okay, so we see that the real threats have nothing to do with tapes (or even disks) in transit. So taking the time and effort in your *DISASTER RECOVERY* tapes to encrypt adds another layer to restore functionality to the dataserver. As you pointed out, MP3.com lost money evey minute that a single https serving server was down, compund that by decrypting the data tapes. Including running around to each to enter the passphrase. I am ignoring the time to get the passphrases, as I assume that it is done in parallel with the tapes themselves. Let's hope the DR plan mentions where the passphrases are and how to get them. I would not want to be the one to sell to the big bosses: ``We MUST have unecrypted secret keys! The time that one system is down, we will lose big $$! We MUST encrypt the disaster recovery tapes! This will cause our entire data center to be down a significant period of time, losing us even more bigger $$$!'' > If it is easy to mitigate the risk due to a swiped SSL key or swapped > out password I do it It is, actually. Especially the latter: encrypted swap. http://linux.ioerror.us/2006/09/encrypting-your-swap-partition-on-fedora-core/ It will likely mean a reboot. Doing it one sever at a time, or during your regularly scheduled maintenance window and you gain a good amount of security with little real cost. The other way is a bt more difficult. If I were to architecture something like that, it would include: load balancer + a number of https servers, each of which is on a UPS. This way they won't all go down on a powerfalure. If it is long enoug, then, yes, they will all go down. I would architecture it so the time for power downage would be Suffcient (however long that might be. Site dependent, of course). When an https server went down, the load balancer would take it out of rotation. Either nagios or the server (upon reboot) would issues a notice to the admin team, begging for attention. If two went down, that notice would become quite critical. Someone should respond in some way before the last https went down. I would have the https servers on remote KVMs, so anadmin could fix the problem from their home. No need to drive in. Not that hard anymore, is 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. What is so special about it? It is Just Plain Smart. I mean, you are taking significant amounts of $$ for being down, right? > >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. Since the data is already encrypted, no need to encrypt it onto tape, right? Good. I think we can agree on that one. > A mysql version migration can be a major undertaking. Not gonna happen > overnight. I agree. That is quite the undertaking, as you have to test all of your applications against it and such. However, you are already using a helper app to encrypt to disk, so no need to upgrade just for that. > Encrypted swap doesn't really buy us much as far as security goes as a > number of other things could. I agree. It only helps in the case of a stolen or shipped disk. > And as I mentioned above encrypting the SSL key isn't practical for > us. I think you missed the point of the SSL key. The theory was: if you can have a mechanism for having an encrypted SSL key, then you can use that mechanism for other applications that need to decrypt their data files (that are storing to the disk encrypted). This is different from encrypted partions, as an encrypted parttion that is dumped to tape is no longer encrypted. The idea was to encrypt the sensitive data, so t is encrypted on disk and on tape, so you don't need the overhead of decrypting in case of Disaster Recovery, and yet stll protect yourself in the case of stolen, lost, or misdirected disaster recovery tapes. Is this more difficult than simply encrypting to tape? Yes. It will also protect you from a lot more stuff, too. Such as the case of missing, stollen, misdirected, or accdentally released hard drives. > 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. You can make reasonable assumptions as to the technical issues. If your assumptions are wrong, revise as updated information becomes available. I find that most people are rather myoptic (myself included) and like to see their own little world. It does take some effort on each persons part to shake out of that viewpoint. -john -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
