Re: implementing a set of queue-processing servers

Rob Nagler wrote:

>>    
>>
>My experience is just the opposite.  If you reuse code, most servers
>contain that code base and are therefore "large" relative to very
>specific applications.  Most of our mod_perl servers are 15MB minimum,
>and grow to up to 80MB.
>  
>
But what if the code is not meant to be reused except within the context 
of what you are processing. But from what you are saying, I suppose I 
would agree that the integration point with Sabre is pretty much 
straight through and not much custom logic.

>The problem is sharing, routing. load balancing, etc.  If you run
>separate processes, there's no chance to share.  If you run separate
>processes, you need more configuration, documentation thereof, and
>design for peak load becomes more difficult.
>
I think that is a good point.

>  
>
>>Maybe this could be segmented using a reverse proxy to make the 
>>difference between whether it goes to a mod_perl process that talks to 
>>Sabre and one that does other app stuff.
>>    
>>
>
>This stuff is handled on the back end.  I don't see where proxies
>would help.
>  
>
I had mentioned the above in the context of providing an alternative in 
case there is no backend.

>>But alternatively, splitting it 
>>out so that the Perl code that does the logic of talking to Sabre and 
>>massaging that for a mod_perl app is stored in POE or PerlRPC, then it 
>>would be better to have the 5 middleware processes dealing with the 
>>shared memory stuff.
>>    
>>
>
>POE and PerlRPC are fatter than the Sabre code, I bet.
>  
>
Yeah, I think you are right. I've not used POE, PerlRPC is fairly thin 
but you are right that it is fatter. So I think this is also a good point.

>>Apache is better than IIS but I would not call it "secure" in an 
>>absolute sense. There have been plenty of exploits for Apache over the 
>>last year that give me headaches having to patch ASAP when discovered.
>>    
>>
>
>Is POE or PerlRPC more secure than Apache? I seriously doubt it.
>  
>
That could be, but how many exploits of POE or PerlRPC or core Perl 
(which would also be exploitable) has been posted on Bugtraq in the last 
year. Very few if any (zero I think?). What about Apache? Definitely Not 
Zero.

This doesn't mean that POE is more secure than Apache, but it does mean 
that there are less publicized exploits. If POE became a popular 
webserver, certainly more people would be trying to break it actively 
and perhaps they would find more exploits.

So...

If you had an Apache server and a POE app server, what would a cracker 
have an easier time trying to get in?

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.

>  
>
>>If you are a cracker and have hacked someone's Apache, but then your 
>>next crack has to find an exploit in a daemon written in Perl like POE 
>>before finally getting to the database or backend system, you are still 
>>slowing down your attacker. Usually at worst, the attacker will have to 
>>figure out something about how POE works.
>>    
>>
>
>The cracker will go to the OS.  They aren't going to proxy-hop.
>They'll try a telnet, ssh, dns, etc. exploit once they are on the
>inside.
>  
>
Sure if you run them on the same DMZ or the same server .The assumption 
is the application server is in a separate zone which only allows 
requests in from the web server and requests out to the DB server or 
other resource. If security is a concern, I wouldn't see someone dumping 
all the code they are running and the database on the same machine cuz 
then if they get into Apache, they have the keys to the kingdom.

>>I believe more script kiddies/casual crackers can probably log into 
>>sybase, oracle, mysql databases and trash them than they can figure out 
>>how to talk to an RMI engine, EJB server, SOAP, or POE middleware for an 
>>application layer prior to accessing the database.
>>    
>>
>
>If this is a large scale app, there will be front-ends, middle tiers,
>and databases.  If they crack ssh, they're through the system.  If
>
How? Why would any firewall admin allow SSH access from the outside 
world to poke progressively inwards through the protected zones?

>they crack Apache, they still have to exploit the specific attack.
>Middle tiers run mod_perl, but not mod_proxy and mod_ssl.  Front ends
>run mod_proxy and mod_ssl, but not mod_perl.  The cracks on Apache
>have all been on specific modules, not on the Apache core.  The weak
>link is not Apache or the middleware, because the connections as you
>point out are too complex.
>  
>
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.

>We digress.  The problem is to build a UI to Sabre.  I still haven't
>
It is a digression, but also an important one. Security of external and 
internal systems is an "Enterprise Level" discussion is it not? :) But 
perhaps this could be separated into a separate subject line.

>seen any numbers which demonstrate the simple solution doesn't work.
>Connecting to Sabre is no different than connecting to an e-commerce
>gateway.  Both can be done by connecting directly from the Apache
>child to the remote service and returning a result.
>  
>
Sure, I can see your point and here, I think you are right.

>  
>