Re: web security (was implementing a set of queue-processing servers)

Rob Nagler wrote:

>Gunther Birznieks writes:
>  
>
>>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.
>  
>
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.

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 :))

>>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.
>  
>
This is not necessarily true. It also depends on the quality of the eyes 
and what the eyes care about.

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.

>  
>
>>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.
>  
>
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.

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.

>  
>
>>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.
>  
>
And many times they are because they are useful. It's pretty rare to 
find a bare Apache.

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.

>  
>