This content has been marked as final. Show 35 replies
We have customers that decline to install "Apache" webservers.Would they feel happier using Oracle XE which uses an embedded PL/SQL gateway then (rather than an external Apache server)?
They demand that all traffic is initiated from INSIDE the the firewall.Well that's easy then, tell them to offer jobs to everyone wanting to use their application, that way they can access it from inside the corporate lan rather than over the internet ;)
To solve this we made a webserver/client solution where the webserver put all requests on a >queue. Then we have a client application on the inside of the firewall polling this queue - and >fetching requests from the web.Ouch...that sounds like over-engineering to me, I'm not sure exactly what this is achieving?
Is your technology 'filtering' the traffic at all? If not, then what is the point of the 'relay' step?
If you can expand on exactly what it is you're trying to achieve and what the clients exact 'issues' with Apache are, then perhaps we can suggest alternatives to what you're doing (making your own 'traffic relaying system' or 'Apache replacement' sounds like a recipe for disaster to me).
Would they feel happier using Oracle XE which uses an embedded PL/SQL gateway then (rather than an external Apache server)?I would not think that they fancy that either.
Well that's easy then, tell them to offer jobs to everyone wanting to use their application, that way they can access it from inside the corporate lan rather than over the internet ;)I'll check if that's a possible solution :-)
The problem with the Apache solution is that you have to open a port from DMZ to the secure network. Our customers have received guidlines for securing their network from the government. Their interpretion of these guidlines are that this is not allowed. You may argue all you want about this beeing silly, but the fact is that we can not sell a web solution where this is done.
Ouch...that sounds like over-engineering to me, I'm not sure exactly what this is achieving?Please see this from a buisiness point of view - WE CAN SELL OUR WEB APPLICATION!!!
Is your technology 'filtering' the traffic at all? If not, then what is the point of the 'relay' step?Yes the "technology" is filtering - but not much more than the Oracle solution.
I belive I have explained what I am trying to do (or have done).
We can not open a port from DMZ to the secure network. ALL traffic must be initiated from INSIDE the firwall.
The poll that the "client application" on the secure network send to the queue on the webserver is connection oriented. That means that the answer from the webserver queue is sendt back as answer over the same channel as the request came in on.
If you give me a real good explaination why opening a port from DMZ (accepting that someone may get full access to DMZ) - is not a security risk I may try to send this to the department writing the security guidlines for this business area.
Please do not ask "How should someone get full access to DMZ?".
Ok, firstly let me explain where I'm coming from. I've been a 'consultant' in the UK for a number of years now and I've pretty much worked on projects in almost every business sector there is (IT, Finance, Pharmaceutical, Government, Telecoms etc). Over those years I've seen and heard lots of good decisions and many more bad ones made. I have come across situations similar to yours before, I have also seen people try and make solutions similar to yours too (many of them ended up as canned projects).
The way I see it, unless you are doing some significant 'filtering' of the traffic in your 'in-between-step', then ultimately it's pointless doing it, since if you are passed through the traffic from the internet to the webserver anyway then what extra security have you added? All you have done is 'convinced' yourself that the traffic is coming from inside the DMZ (it's not...it's still coming directly from the internet, you have just relayed it internally yourself to 'appear' as though it's initiated from within the DMZ...there is no added security there).
The poll that the "client application" on the secure network send to the queue on the webserver >is connection oriented. That means that the answer from the webserver queue is sendt back as >answer over the same channel as the request came in on.How is that adding anything to the security? By your own admission, you are simply relaying the traffic from the internet (whether it's maliciously crafted or not).
There may be other options open to you, for example you could install another Oracle instance in your DMZ and keep it synced with your main server (which is inside your internal network) using streams or some other method. It is possible to configure network filtering such that traffic can be initiated from your internal network (or some other location) to the DMZ but not vice-versa (if you don't have the abilities to do that in-house then you should seek the help of a network engineer, it is not an uncommon requirement).
You can also buy network devices that will examine and filter your network traffic if they detect any malicious payload (for example if someone tries to perform some SQL injection etc). Currently I don't know of any that will filter specifically for APEX maliciously encoded URLs, but then I also don't really know of any outstanding malicious APEX URL's that can be hand-crafted either. However, these devices usually allow you to add custom rules etc, so if you discover any flaws in the future then you would be able to create your own custom rules to filter any HTTP traffic that tried to exploit those flaws.
I could be missing the point here, but I don't think that building your own 'traffic relaying' system is adding anything to the mix security wise.
first of all - let me point out that I did not come up with this idea. I am just the one that have to fix it :-)
Anyway I've have worked 12 years in Telecom/IT myself, and I know that if you can't sell your application you won't earn much :-) The customer is always right :-(
We are doing significant filtering. But I belive Oracle is doing that as well, haven't really checked.
THE POINT is not the actual traffic from Internet. What the security guidlines argue is that an open port from outside into the database gives hacker possibility of taking control of the database. E.g. performing sqls.
I have not seen any good documentation why this can not be done. All people say is that the existing solution is safe because it has been used a lot...
The solution we have at the moment is working. No problem - it is actually faster than the Apache solution (I assume it is because of the way DB sessions are handled), and more scalable.
All that I am asking is if anyone know how APEX works. The API for APEX - that's what I am looking for... Scraping our webserver solution is another discussion... If it does not exist we probably won't go for APEX and stick to the solution we have today... Possibly improve that instead of going for APEX.
I did not come up with this idea. I am just the one that have to fix it :-)Oh I can completely sympathise with that situation, I've been there myself many times ;) However sometimes I believe you need to put your hand in the air and shout "that idea sucks" ;)
What the security guidlines argue is that an open port from outside into the database gives hacker >possibility of taking control of the database. E.g. performing sqls.Then your clients should be happy...there is no open port from outside into the database. The open port is to the webserver, not directly to the database (although obviously it is 'indirectly' to the database).
All people say is that the existing solution is safe because it has been used a lot...That's because it's true...
Remember it is MUCH easier for you to disprove that it is secure than for us to prove it is secure. For us to prove it is secure we have to show that it is secure against EVERY and ANY attack, for you to show it is insecure you only need to show us a SINGLE example of it being insecure....just a single example ;)
The solution we have at the moment is working. No problem - it is actually faster than the >Apache solution (I assume it is because of the way DB sessions are handled), and more >scalable.That is a very bold claim, infact I'll go even furthur...perhaps you should market that rather than your other product ;)
What makes you say it's more scalable? How have you tested that?
If it does not exist we probably won't go for APEX and stick to the solution we have today... >Possibly improve that instead of going for APEX.I'd love to see you go with APEX and I'd love to be able to help you to so that there's another site out there using APEX. However I really believe you're heading down the wrong path on this one, sure your client might be worried and have concerns about security (which client doesn't?). However the solution to that is to show the client how secure the solution is, not to try and create something that adds nothing to the security (since that would be deceptive to the client).
Another question springs to mind, how are you going to maintain your solution with APEX upgrades? Are you always going to have to rewrite your solution to handle the new facilities that each new release of APEX provides?
Also, aren't you putting your client into dangerous "Oracle Support" territory? What happens when your client has a genuine support issue and contacts Oracle Support? I'm betting the moment that the client tells Oracle support that they are, rather than using a certified OHS/IAS webserver, they are infact using a 'homebrew solution' that Oracle Support may be extremely limited in the amount of support they are able to give.
To me, being supported by Oracle by running a certified and recognised installation should be as much a concern to your client as the security issue.
I assume you work with oracle. So you probably know that we are an oracle partner. Our customers don't contact oracle support - they contact our support organisation, and if applicable we contact oracle support. We certainly will test the problem with Oracle's Apache solution to see if the "fix" the problem - if it does we will of course not contact Oracle Support...
Oracle was not able to provide our clients with information that was acceptable to them.
We considered all the problems you mention - but how can we sell a product our clients deny to use. Oracle haven't been able to argue agains their conserns - how can I do that then???
I can disagree all I want. It does not help much :-(
I haven't dug into the Apache solution - others have done the pre studies. However on line you wrote made me wonder:
In DMZ there is a server machine/server - right? On the "secure network" there is anoter machine/server. Between these there is a firewall. It is the configurtion of this firwall that is problematic.
there is no open port from outside into the database. The open port is to the webserver, not directly to the database (although obviously it is 'indirectly' to the database).
There must be a port open FROM DMZ to the "Secure network" for APACHE to work - correct?
This is what must be avoided. How can this be done without a queue/polling implementation?
Anyway - the question is not how we will cope with upgrades - the question is if APEX is documented or if it is just an "black box"?
I have made my conserns clear - but I am not the one making decisions... So it does not help me that you continue stating that I'm stupid going for this solution. I only need to know if there is an API or not...
I assume you work with oracle.No, I don't work for Oracle, I don't speak for them....my opinions are my own as they say ;)
Oracle was not able to provide our clients with information that was acceptable to them.You would need to take that up with Oracle. The most knowledgeable APEX people hang out in this forum, including most (if not all) of the APEX development and management team themselves. So if you can't get a satisfactory answer to your question then I don't know what to suggest (except perhaps change your perspective on it? Approach it from another direction perhaps?).
but how can we sell a product our clients deny to use.But as I said, what you propose is not solving any security concerns at all (from what I can see). I could sit down this afternoon and write a C program that would proxy traffic between your networks and therefore 'satisfies' the requirements of your client that the traffic does not 'originate' from the Internet....but it adds absolutely nothing to the security of the overall design.
There must be a port open FROM DMZ to the "Secure network" for APACHE to work - correct?If you want the Apache server to connect to an Instance inside your 'secure network' then yes you will need to be able to route traffic from the DMZ to inside your 'secure network'.
How will your method achieve the same result if there is no network route between them? I am curious.
How can this be done without a queue/polling implementation?How does that solve the security issue you mention though? If I carefully craft some malicious payload, it will be stuck into your queue, your implementation will then pass that malicious payload along to the server.....how is that in any way 'more secure'?
As I said before, unless I am really missing the point with your infrastructure then writing your own 'polling queue' is not adding anything to the security mix.
the question is if APEX is documented or if it is just an "black box"?APEX is not a 'black box' it is extremely well documented, all the docs are available from here -
So it does not help me that you continue stating that I'm stupidNot once have I said the word 'stupid', I have posted over 2700 messages in this forum and not once have I descended to personally insulting someone, nor would I do so.
I am trying to dissuade you from creating all this extra work for yourself, when I do not see what good it is doing, that is not a personal insult trust me.
As I have mentioned before, unless you are going to build a full 'potential exploit filtering' solution then you are not making the solution any more secure, since you are ultimately only passing on the payload that was generated by the remote user anyway (unless I have completely misunderstood what you're trying to do, if so then please feel free to re-explain it again so that I can understand it).
Really, I do understand (or at least I think I do) what you're trying to do. Years back I worked on a project for a Telecommunications company who invented a huge amount of money in some queueing technology from a three letter company (I won't mention the names, but it's easy enough to work out which one I mean) precisely because someone high-up didn't like the idea of the traffic being initiated from the remote end. It was pretty much exactly the same scenario you describe you have.
A huge amount of money was spent implementing a queuing system that jumped across routers, subnets and systems....but ultimately the point was lost that we were simply relaying the same traffic that arrived at the original end-point, i.e. we had created 6 months worth of work, spent lots of money and ultimately had made the system no more secure than it was before.
If you are not filtering the traffic then relaying it makes it no more secure, I can't say it any clearer than that really.
Perhaps someone else might jump in and offer other suggestions here which will help you, but personally I think it's the wrong solution for the situation.
Do you know that Oracle are moving towards the Embedded PL/SQL gateway in 11g? In other words there will be a webserver built into the database from the ground up? Could there be security holes in this? Sure...software is software, as long as there is software there is the potential for security holes. However since it will be a 'core' part of the DB, I have faith that Oracle will act quickly to patch any problems that are found (as they do currently).
As I said at the top of this post, these are just my personal opinions, but I've seen people go down the track you're heading down...and in my experience you're making more work for yourself than you have to.
Address the clients concerns, have someone who is knowledgable about APEX and the APEX architecture sit down with them and address each and every one of their concerns, that (to me) is the best way to give value to a client.
You could put an Apache 2.0 server in the DMZ and have it proxy requests to the OHS which is inside your network and you would pretty much achieve the same end result as you have got (i.e. as far as the DB is concerned the traffic originated inside the lan since it came from the OHS and not the external Apache 2.0 server).
thanks for taking interest in my case.
I have to apologise - you never insulted me in any way. Just a bad phrasing on my behalf - sorry.
Thanks for the links - I will dig into that information.
I see your point. I will bring it on - but I don't think I will get acceptance. I have no documentation to refer to - and as I said Oracle haven't been able to convince our customers...
The solution we are using today took about 400 hours to develop. This includes our own webservice solution. The plan is to build in SMS as well.
Our solution do screening of all incoming traffic.
The requirment I have been presented with:
Requests must NOT originate from DMZ (outside the firewall to the secure network).
All requests must originate from inside the secure network.
Requests must NOT originate from DMZ (outside the firewall to the secure network).Then, in all seriousness, people external from your secure network cannot access the application, since otherwise the requests would originate from outside the secure network. No matter how you slice it, that requirement cannot be met if you want to allow people external to the network use the application.
All requests must originate from inside the secure network.
I would suggest looking at the architecture I suggested (Apache 2.0 server in the DMZ, proxying requests to the OHS which sits inside your network). I know of lots of companies using this setup and have not heard of a single security incident yet that is directly attributable to that infrastructure.
Our solution do screening of all incoming traffic.But what are you screening for? Are you aware of some flaws in APEX that the rest of us are not aware of? (seriously!)
The solution we are using today took about 400 hours to develop.No disrespect to your solution, however as I mentioned before the mod_plsql handler has been in existence for a long time now and has been 'proven' out in the field in a great number of different sites, it is being used both for the AskTom and Metalink sites so far as I'm aware (i.e. it is the same one you and I can use).
By request I mean the actual signal - Apache solution: The signal is sendt from DMZ to the Secure network.
In our solution it is sendt from: Secure network to DMZ. The actual traffic must off course come from internet.
I think you understand what I am trying to say - though you twist it around :-)
Do you have a link to a document describing a setup of Apache 2.0 server with proxy? We have to provide proper documentation to satisfy our customers.
I was just told that another drawback with the Apache solution (which will be solved in 11g with embedded webserver - maybe in 10g as well) is that there must be an oracle installation in DMZ. Forcing our customer to pay for two oracle licenses (according to Oracle).
I was also given this link:
I have not had time to check up on this, but it seems not everyone is satisfied with the solution... BUT, as I said I have not had time to look into this article - it might be bullshit...
Seriously - I have not claimed that there are any flaws with APEX screening!
But you asked if we screen the traffic - and we do.... I don't say that APEX doesn't screen...
In our solution it is sendt from: Secure network to DMZ. The actual traffic must off course come >from internet.That is just 'semantics', if you draw a diagram you will see that your solution is merely relaying the traffic (via the queue) that is generated by the end user from the internet. I can't really say this any other way, you are not making the traffic originate from inside the secure network...you are relaying traffic that was generated from outside.
Do you have a link to a document describing a setup of Apache 2.0 server with proxy? We >have to provide proper documentation to satisfy our customers.Sure, but that is really an Apache issue, you can find details here (links for both Apache 2.0 and Apache 1.3) -
Also, search these forums, there are many people using this kind of setup (including myself).
I was just told that another drawback with the Apache solution (which will be solved in 11g with >embedded webserver - maybe in 10g as well) is that there must be an oracle installation in >DMZ.No, not necessarily you can sit your Apache server in the DMZ but open a network route to either -
1) Another Apache server inside your DMZ which has requested proxied to it (as I described earlier). This could be the OHS/IAS or even another Apache server if you wanted to.
2) Connect to the database assuming that the Apache server in the DMZ was the OHS/IAS.
So, no you don't necessarily need to install another Oracle database in the DMZ (although that is certainly an option).
I was also given this link:That story is over 18 months old and if you dig around you will find the solution to it. Again, I don't see how your solution is any more secure than this? In your scenario you would simply have relayed the same exploit via your queue.....no? Or are you saying you would have pre-empted this exploit by coding something into your queue management tool?
Hi user499808 (you can go to "Your Control Panel and actually let us see a name instead),
I've been watching this discussion and am still bit confused.
Your (actually your clients) requirements, are that a webserver sits in the DMZ.
One, and only database, resides inside the secure network.
Traffice between the DMZ and the secure network is (of course) heavily regulated and restricted.
The client wants the unsecure webserver in the DMZ to somehow magically communicate with the database within the secure network.
The client wants all database (or is it webserver?) traffic to originate from inside the secure network, but still have the ability to send the results back to the "outside" network (internet)?
I'm confused by now at this point. Is this for an application that is only used within the secure network, or is it also used by "outsiders" via the internet as well?
If it's only internal users, then it's no big deal. Simply have the Oracle Web Server inside the secure network and not accessible to the outside world.
If however, the client only wants one webserver and one database, both accessible (somehow), to both internal and external users, then I can see your problem (or question).
So, if the above statement is correct, in that the application has to be accessible to both internal and external users, and the database resides within the secure network while the webserver is outside of the network, I think it all can still be accomplished several ways.
Digressing temporarily to your first post though. the f procdeure is wrapped because Oracle doesn't want to allow people messing around with it, as that will cause future problems. There would no way for Oracle Support to ever know if the procedure was modified by the user and that is what caused the problem vs. something that really is within that code (though it's highly unlikely at this point in time).
So, in a nutshell, most of the Apex procedures, packages, etc. are wrapped for a reason. There is documention available on how to call them, what parameters are allowed or expected, etc., but not the details on how they actually accomplish the end result (unless you search the web for PL/SQL "unwrappers").
Back to your problem though. One problem I instantly see (and get confused by), is your statement "We can not open a port from DMZ to the secure network. ALL traffic must be initiated from INSIDE the firwall."
Without any ports open between the DMZ and the secure network, there is no communication. So, there would be no way at all for a webserver to tell the database or a polling system or a queue that "I want this information". Something has to be open, even if it's a non-standard port. Either that, or there is a HUGE army of clerks sitting around waiting for somebody to hit the webserver with a request, then they re-type the request within the secure network, and then somehow magically that gets transmitted to the original requestor.
So, since at least one port HAS to be open between the DMZ and the secure network, here's one scenario:
You have Oracle Application Server (the Apache web server) in the DMZ. Being within the DMZ, security isn't as much of an issue since everything in a DMZ is automatically classified as insecure, right? Any web server within the DMZ will have to be classified as insecure, since that's already the definition of the DMZ, "Nothing secure resides within the DMZ". So, once again, using the OAS isn't really an issue.
So, the problem now is how to have something that is automatically classified as "insecure" communicate with something that is secure.
You can have a read-only database (Oracle XE perhaps, since it's free?) within the DMZ that uses database links and views on those links to get the requested information from the "authorized" schemas in the secure database. None of the data would reside on the DMZ database, it exists soley to extract valid information from the secure system.
The drawback is if you use LOBS. As I understand it, there is a problem using LOBS across database links. There may also be some licensing issues with XE for a production system, I really don't know for sure. If so, then you would probably need to get the customer to get a license for the Standard Edition to keep in the DMZ.
Another way, but still requiring two databases, would be to periodically copy the information from the secure database to the "unsecure" database, and then physically carry the CD's or tapes or whatever over to the "unsecure" database to load.
Maintaining only one database with absolutely no open ports between the DMZ and the secure database just can't happen can it? Something HAS to be open.
thank you for your answer. I expected that the internal detail of APEX was "hidden" - it makes sence... Thanks for that answer - this was my actual question :-)
I'll try to explain the "problem" once again.
There are users of the webserver both internal and on the internet.
The webserver must be in DMZ (the unsecure sone).
The customer allows us to open a port in the firewall - but only for connections originating from the secure network.
So this is the open port - but that will block for requests from the Apache server since this connection originate from DMZ.
Using a connection oriented protocol like TCP we implemented this polling logic. There is no clerks typing requests like mad :-)
I hope this explains it?
We considered the "replica" database - but that was not acceptable because of privacy issues. Theres also problems since data can be updated over internet as well as using internal application (in addition to going over the web).
So this is the open port - but that will block for requests from the Apache server since this >connection originate from DMZ.
Using a connection oriented protocol like TCP we implemented this polling logic. There is no >clerks typing requests like mad :-)That still doesn't make sense to me, can you explain how the traffic is getting from the DMZ to inside your secure network if there is no network route open between the two?