The advantage of being an Apps DBA -- Quick conf. for DMZ Reverse Proxy Configuration for OBIEE & Analytics

As required by my position in recent years, my primary focus has been on Exadata, Core Databases, ODA, virtual machines, Hadoop clusters, OCI, GCP and Linux. However; those who know me, may remember that, I was spending almost all my time with EBS and Middleware in the past.

In this blog post, I will give you the benefit of being an APPS DBA. I will explain this through an example and show you how easy an APPS DBA can implement avanced middleware and web tier configurations when there is a need..Especially, when they expect a DBA to do such configurations...

This is ofcourse, a benefit of dealing with EBS.. As you may already know, EBS is tone of the most complex software systems in Oracle world. EBS contains many technologies. While administrating EBS environments, the nature of the EBS automatically makes you an expert in these technologies.

This is the key benefit that every DBA should have .. Especially. in these days when we consider cloud migrations.. In my opinion, DBAs with apps, middleware, systems and network knowledge will be advantageous on cloud operations and management.

Anyways, recently, a OBIEE system was required to be accessible from the internet. Not only the OBIEE but some other urls that are host by the OBIEE node should also be accessible from the internet. DMZ was the first thing that crossed on my mind.

This one was actually a pure middleware admin, web server admin , in some cases a system/linux admin work, but my team and I volunteered to do it.

We volunteered, beacuse we were already giving Managed Services for critical EBS environments, and we already knew what a DMZ is..

We knew how to implement a DMZ configuration for EBS. We knew Apache and Oracle HTTP Server. OBIEE was running on Weblogic, as EBS does :) We knew the required configuration. We also knew the recommended configuration as we were living in EBS world :)

Anyways we got the job, and as a trusted advisor I recommended a list of configurations to our customer.

As for the reference and lookup, again EBS documents were the keys :)

Oracle E-Business Suite R12 Configuration in a DMZ (Doc ID 380490.1)
Oracle E-Business Suite Release 12.2 Configuration in a DMZ (Doc ID 1375670.1)

Ofcouse there are several configurations and they depend on the security level that you are targeting. Reverse Proxies, External Tiers , Internal Tiers, Data Firewalls and so on..

However, in this case, we had to find a balance between security and ease of management.

Our purpose was to configure DMZ for OBIEE, in order to make it available for the internet access.
OBIEE was working with a full path TLS.. (this is almost a must when you consider internet access). 

We had 2 firewalls , one of them was in front of the DMZ and the other was located behind the DMZ. This is also the minimum firewall requirements in these types of cases.

Customer didn't want to have an extra node. Customer didn't want to increase the management efforts, either. 

So we decided to implement a reverse proxy configuration.

Note that,  a reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers.. You can think it like, it is a proxy which operates in a reverse direction :)

Do you remember the difference between Forward Cross Edition triggers and Reverse Cross Edition triggers, that we use in Online Patching in EBS 12.2? The logic is similar :) Joking :) It is not that..

Anyways..

After this long introduction, lets focus on the implementation and the configuration that was done for the reverse proxy.

DMZ (demilitarized zone), known  by the name, is a purified zone in the network. It is a sacrificial area and it is a common requirement in security audits. 

Basically, we configure a zone between the external firewall and internal firewall and use it as an extra layer for the applications, which are required to be accessible from the public network.

We can use DMZ configuration for giving puıblic or external network access to the services such as FTP server, Mail Server or even EBS services. 

When we configure it correctly and securely, we can make the required modules our services of our applications or solutions be communicatable through the outside network, without compromising the security of our internal network.

In this context,  we implemented a reverse proxy-only DMZ configuration for OBIEE and some other services. We implemented a reverse proxy -only configuration, because ot the reasons I mentioned before. 

Following diagram shows the configuration that we have implemented for this specific case;

We have used Apache here. Ofcourse, we could have used Oracle Http Server , as well. The installation was simple.. The configuration was also simple , but it was a little tricky :)

1. First of all, we installed httpd (Apache) on the server (Oracle Linux 7), which was to be used as a reverse proxy server in DMZ.

yum -y install httpd

2. We disabled SELINUX and Firewall. (Note that, these are just the quick and easy steps to give you the idea.. You can leave your firewall and selinux running.. However; iff that's the case you should configure your firewall and selinux to permit the communication needed by this configuration)

vi /etc/sysconfig/selinux
SELINUX=disabled
systemctl stop firewalld
systemctl disable firewalld

3. On the reverse proxy server, the httpd.conf file located in /etc/httpd/conf.

We configured our Apache which was in the role of a reverse proxy and responsible to redirect all http requests that are made to http://dmz_rev_proxy_host/analytics.. Our reverse proxy should have been redirecting those request to the internal host -> http://internal_host_analytics: 9402/analytics.

We used multiple Location tags for redirecting multiple ports and addresses to the multiple internal urls. The ProxyPass directive was the main proxy configuration directive.. It was used to redirect the requests to the server on the internal network.

ProxyPassReverse directive was another important directive, and it was used to avoid bypassing the reverse proxy.

Ofcouse there are other parameters that need to be set according to your needs, but I will not dive that deep in this blog post.. 

Nevertheless, you can always write me if you have any questions. (for your questions, please use my forum -> http://ermanarslan.blogspot.com/p/forum.html)

So, our goal was to redirect the following DMZ node url requests to the following internal OBIEE node -> 

DMZ urls:

http:///dmz_rev_proxy_host:9402/analytics
http:///dmz_rev_proxy_host:9402/va
http:///dmz_rev_proxy_host:9402/dv
http:///dmz_rev_proxy_host:9402/bi-security-login

Internal OBIEE node urls:

http:///internal_host_analytics:9402/analytics
http:///internal_host_analytics:9402/va
http:///internal_host_analytics:9402/dv
http:///internal_host_analytics9402/bi-security-login

Note that, I am giving you some example urls, and as you see they are just http urls.. 

Again, ask me if you have any questions about reverse proxy configuration for SSL/TLS urls.

Now that we know our urls, let's look at the parameters we added to httpd.conf to achieve our goal.

vi /etc/httpd/conf/httpd.conf

<VirtualHost *:80>
<Location "/analytics">
ProxyPass http://internal_host_analytics:9402/analytics
ProxyPassReverse http://internal_host_analytics:9402/analytics
Order allow,deny
Allow from all
</Location>

<Location "/va">
ProxyPass http://internal_host_analytics/va
ProxyPassReverse http://internal_host_analytics:9402/va
Order allow,deny
Allow from all
</Location>

<Location "/dv">
ProxyPass http://internal_host_analytics:9402/dv 

ProxyPassReverse http://internal_host_analytics:9402/dv
Order allow,deny
Allow from all
</Location>

<Location "/bi-security-login">
ProxyPass http://internal_host_analytics:9402/bi-security-login 

ProxyPassReverse http://host_analytics:9402/bi-security-login
Order allow,deny
Allow from all
</Location>
Redirect Permanent /bi-security-login http://internal_host_analytics:9402/bi-security-login
ProxyPreserveHost On
</VirtualHost>

Note that, the Redirect Permanent parameter provides a permanent redirection to the bi-security-login page. We needed it, because 9402/va was redirecting to the http://internal_host_analytics:9402/bi-security-login.. The address in the browser's address was changing to the internal server's url and we didn't want that.

4. After making our changes in httpd.config, we restarted the httpd service.

systemctl stop httpd

systemctl start httpd

5. After these processes are completed and ofcourse after the customer completed the required firewall configurations and the network configurations for the internet access to the DMZ node and port, we could be able to access the analytical interfaces hosted by the analytical server in the internal network from outside the network, through the DMZ server.

As I finish my writing, I want to add 2 more things.

Be careful while dealing with reverse proxy configurations..If you change your urls, I mean if you use a configuration that  rewrites the urls on the fly, your styles and other links that you use in your applications may fail to load. So your applications should be compatible for this types of reverse proxy  configurations.. If they are not, you may still find a solution by using some extra directives in the httpd.conf.. Ofcourse if you are lucky :).. So in some cases, you may need to review and improve the code.. I mean the web-related code. That's why, always work with your apps teams while implementing this type of configurations.

Lastly, I have given you a basic reverse-proxy only configuration in this blog post.. But ofcourse it is not that secure.. Review the EBS notes that I shared with you earlier in this blog post and find the one that suits your needs..  I recommend you break the balance between security and ease of management, of course in favor of security :)