Re: implementing a set of queue-processing servers

[Gunther Birznieks]

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.