Rob Nagler wrote:
Gunther Birznieks writes:Assuming constantly up-to-date code, there would be no vulnerabilities in either server. It would take an "active" cracker (of which there are fewer than there are script kiddies) to really plug away and figure out how to find a vulnerability from scratch.
If you had an Apache server and a POE app server, what would a cracker have an easier time trying to get in?Assuming up-to-date code, POE, for sure.
However, even then, I think you are not entirely correct. Let's assume I have all the time in the world and let's assume I am lazy about pouring through code to discover a vulnerability for myself.
If I am biding my time (am I on a real deadline to crack your site?), then I will just wait for the exploit to be discovered and publicized about Apache and attack the Apache server rather than your POE server.
As POE has less expoits publicized, it is more likely that a buffer overflow or the like will be discovered in Apache first and I will be ready to write injection code to exploit that vulnerability prior to the fix being released from Apache.org.
That will surely be easier than figuring our the vulnerabilities for myself. Allowing an exploit to be posted will let me be a part-time cracker and all I need to do is wait with a skeleton of injection code, ready to strike when the exploit is publicized. But in the latter case (finding vulnerabilities myself), I will likely have to make it my full time job (either that or I would have to be a high school/college student :))
This is not necessarily true. It also depends on the quality of the eyes and what the eyes care about.Probably the Apache server. Once broken through the Apache server, the cracker would have to figure out that it is indeed a POE server on the other end, and then to figure out an exploit by just trying as many things as they can. ie they'd have to do a lot of extra work rather than utilizing a public knowledge exploit someone else discovered.All public knowledge exploits of Apache are fixed within days if not
hours. It's the private ones I worry about. There have to be more
of these in POE than Apache. The more eyes, the fewer the defects.
I think Apache is an example of a product that is arguably more secure not because of the amount of eyes looking at the code, but the quality of the eyes.
For example, Apache is of interest to the security community because it is frequently the first line of attack and so it gets attention of quality eyes looking at the code.
Whereas, you will much less likely see a security audit on someone's EJB or POE server because it is not on the front-line. And the majority of eyes looking at POE are developer eyes whose mindsets are on creating functionality (the mindset of a developer), not destroying/bypassing functionality (the mindset of the cracker/tester).
An example where I think you are wrong about the number of eyes (and why I think quality of eyes is more interesting) is sendmail versus postfix. Arguably sendmail is what more servers are running in the world, but postfix has had in a similar time of existence, arguably less exploits and less severe exploits when those were discovered.
This isn't because more eyes looked at postfix than sendmail, but that the "eye" that designed postfix was a security-minded eye and his friends who are also security minded also likely had a hand in audit.
What I mean is that if this were a secure site, you would never allow SSH to come in from the outside layers to the progressively internal layers. Connections should only be allowed from inside out.
How? Why would any firewall admin allow SSH access from the outside world to poke progressively inwards through the protected zones?When we want to get to the middle tiers, we go in through the front
ends. You need passwords at every level. I'm not sure what you mean
here.
So if you have a separate firewall protected zone for the web server, the app server, and the db server, then you would allow the intranet to access the db server, and then the db server to access the app server and the app server to access the web server using SSH. But you won't allow the other way around. Even then it is arguable whether you would allow SSH from the inside out either.
So if someone cracks your web server which you have to assume will be the case, then you should not allow the web server OS to be configured in such a way (as well as FW rules) such that the cracker can then hop onto the Intranet or the App Server directly.
The only thing the web server should have access to is the protocol and port to access the app server.
And many times they are because they are useful. It's pretty rare to find a bare Apache.
I think this is correct. But as most servers that are transactions have mod_ssl, I kind of consider mod_ssl and other modules as being fairly "core" to Apache.They have to be configured to be exploited.
But in any case, I think my first and primary point has also been lost.
In a 3 tier application where the access to the app server and DB server are also protected by FWs then if a cracker cracks the Apache web server, they fact that they have to crack the app server which is running a separate set of code (eg POE) is going to be a major hinderence.
Let's assume that 2 vulnerabilites are publicized a year on Apache and POE. Then it is highly improbably for a vulnerability to be posted about both on the same day.
Your cracker is definitely going to attack your Apache as soon as the Apache vulnerability is posted. But if she gets in one the first day, then she will be stopped from further access because she won't know how to exploit the up to date POE server.
In other words, even if you can argue with me successfully that POE is less secure than Apache, the fact that they are different pieces of software, and the fact that they would be configured in layers, would mean that you definitely have extra protection when you have POE between Apache and your DB server (or other back-end resources like a back-end host).
However, even if you are thinking a cracker will discover vulnerabilities from scratch, and you "think" it is easy to do so on POE, I think you are still majorly hindering the cracker by having POE exist.
First, the cracker won't know that the web site is using POE as an app server until she has broken into Apache.
Then, once discovering POE is the hinderence, the cracker will have to learn Perl enough to be a moderate expert. But even assuming she is good at Perl (how else does she write her cracking scripts) then she will probably need to spend a day or more pouring through POE code off of CPAN to see if she can find any exploits.
In the meantime, that is 1-2 days with which you may be able to trigger intrusion detection...
My belief and sentiment is that you must always assume your Apache is vulnerable and will fall over with the drop of a pin. It might not be that way today or every day, but as soon as an exploit is publicized, it may be like that for an entire day or two. So if you really require the security on your site, having an app server will help you.
In summary, I think it is much more plausible that your DB server (or mainframe host) is toast if all you have as a layer in front of it is Apache than if you have an App Server layer between the two.
