<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Jan 29, 2010 at 11:25 AM, Amos Shapira <span dir="ltr"><<a href="mailto:amos.shapira@gmail.com">amos.shapira@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 29 January 2010 18:43, shimi <<a href="mailto:linux-il@shimi.net">linux-il@shimi.net</a>> wrote:<br>
> On Fri, Jan 29, 2010 at 3:06 AM, Amos Shapira <<a href="mailto:amos.shapira@gmail.com">amos.shapira@gmail.com</a>> wrote:<br>
><br>
> Shouldn't your question be: "if someone managed to get root access to my<br>
> machine, which is what's needed to read the key file which is chmod 600 with<br>
> uid 0, what stops him from reading the key from the process memory of an<br>
> already running Apache without restarting it even I don't store the key on a<br>
> file?"<br>
<br>
</div>Does Apache keep it in plain text in memory or maybe it obscures it<br>
until it's actually used?<br></blockquote><div><br> "Until it's actually used" ? It's used in every request... no?<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
><br>
> Not to mention that if the attacker got root access on your machine (and<br>
> sometimes even less than that, enough to read your scripts with the DB<br>
> credentials) - what do you care if he could read sessions between the server<br>
> and the client, if all the sensitive client data is stored plaintext on the<br>
> DB (or with a reversible encryption that utilizes a key in the code which<br>
> equals plaintext...)<br>
<br>
</div>Our front line web servers do not store any static data, they transfer<br>
it to servers on the internal network. We also aim to do the same for<br>
log files on the DMZ (have issues with syslog performance).<br>
<br></blockquote><div><br>I do hope the Internal network is actually a "backend network", and not your real Internal network... :)<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We hear that Akamai don't store certificates on their front line<br>
servers at all and have them shipped to the servers on-line.<br></blockquote><div><br>The SSL termination point must present a certificate to the connecting client; If the front server does not do that, and handles the connection to a backend, it effectively means the frontend is a stupid TCP proxy (unless I missed something) or even a simple NAT / load balancing device; Not an actual HTTP server... if IP translation is the only thing it does, I think it is a bit redundant... but again, that's just me :)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> I mean... I don't think it's "security by obscurity" simply because I<br>
> believe this measure is not obscuring anything useful...<br>
><br>
> I think you should concentrate your efforts on maximizing web scripting code<br>
> quality and input validation, using multi-tier security mechanisms if<br>
> possible (like web servers chaining and/or privilege separation between<br>
> different parts of the code that needs different DB access privileges),<br>
> chroot jails, watch for security advisories on the software you chose to use<br>
> at all tiers (don't forget the Kernel) etc... I believe it would make your<br>
> security much better than fiddling with a private key file that only root<br>
> can read on your server...<br>
<br>
</div>Part of this is how corporations make decisions, some of our clients<br>
want to give us SSL certificates for servers under their domain names<br>
and will feel more comfortable with us telling them that we don't<br>
store them in plain text. When others (like - competition) tell them<br>
the same you have to play by these kind of rules.<br>
<br></blockquote><div><br>OK, but that's a marketing decision. It has NOTHING to do with security. Your question was how to secure this. If you want to know how to sell it, you need a marketing guy :) You could try to explain that your competition is busy with telling stories and buzzwords, while YOU take care of what's IMPORTANT. They might believe it and might not, but again, this is a marketing venue... It's OK to do what you said you want to do, as long as you keep in mind that you're adding nothing to security, and you're adding complexity instead; From my experience, complexity tends to be the enemy of Uptime. YMMV :)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Same reason we are looking at hardware load balancers even though we<br>
are very happy with LVS - that's the kind of stuff corporations make<br>
decisions about.<br>
<div class="im"><br></div></blockquote><div><br>Exactly my point. The HW load balancers (well, most of them?) are probably PC appliances running code not much different than Nginx/Varnish and friends. I know some hardware "accelerators" use actual proprietary hardware to be able to process a huge amount of connections / attacks, but again, those are prone to bugs just like software is, though are probably much harder to fix when a bug is discovered...<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
><br>
> And finally, Apache is a huge bloat; The more bloat you have, the more you<br>
> sacrifice on performance, and in my opinion, security. The less code that<br>
> runs to serve your requests, the less chance for security issues down the<br>
> road; But that's just me :)<br>
<br>
</div>I keep digging into our product management chain my concerns about<br>
using Apache - not just for security but even for plain speed. But<br>
it's deemed by Dev to be a none-trivial effort to move away from it to<br>
when higher priority tasks are still on the plate (part of our Apache<br>
code is written as C++ apache modules).<br>
<br></blockquote><div><br>That's sad to hear :| Been there, done that... wish you luck! :)<br> <br></div>-- Shimi<br></div><br></div>