How to Access Oracle GridControl 10.2 Agents via HTTPS/Port 443

I’m a Linux fan, and when it comes to specific problems, I’m afraid not all operating systems are equally armed. Enabling a specific user to listen on a port below 1024 is one of these problems that was solved for years with various approaches:

• The Windows approach: we just don’t care!
• The Solaris 10 approach: we have an advanced privilege (net_privaddr)
• The Linux approach*: you’ll find a way to make it work anyway (man setuid)

So you may think, obviously you can access the GridControl 10.2 agent on Linux with HTTPS only, on port 443! And obviously you can — but:

1. The agent cannot listen on port 443 on Linux because it uses the OC4J HTTP listener and cannot run under port 1024. I didn’t try to install the agent as root and you may know something I don’t.
2. You cannot, with 10.2, set up an HTTP front-end, like Apache, for your agent. That’s because the agent sends its listening port to the Oracle Management Server (OMS) so that the OMS can interact with it.
3. Here is a section of EM 10.2.0.4 documentation, you may want to consider: “The final step in that configuration process is to restrict uploads from the Management Agents to secure channels only. Before completing that step, configure your firewalls to allow both HTTP and HTTPS traffic between the Management Agent and Management Repository and test to be sure that you can log in to Enterprise Manager . . . “
4. There is another interesting section of the documentation. It explains that the OMS directly accesses the target database with the Oracle*Net Protocol.

Regarding the last point, you can open the firewall to Oracle*Net traffic or have a look at Connection Manager (CMAN) to create a kind of Oracle*Net DMZ access to your databases. I’m wondering if SSH tunnels are reliable enough to handle this? I wouldn’t use it.

I know I least one other way, but I need to keep some material for future posts.

Part 1: How to Make the OMS to Agent Traffic via port 443

Can you use only port 443 between the OMS and the agent on Linux? The answer is obviously yes, and here is at least one approach: port address translation. And the beauty of it is that Enterprise Manager won’t even notice. This diagram explains how it works:

Let’s assume your agent will run on a host named “target” and its IP address would be 10.0.0.1. What you’ll do is set up port address forwarding with iptables before installing the agent. In order to do that, check that the default agent listening address is not used on target (or change 3872 for another unused port). Then, make sure iptables is started on both the OMS server and the target server, and define 2 rules:

• The first iptables rule is defined on the OMS server, and it says that every time there is an outgoing tcp connection (and all the transmitted packets after that) sent to port 3872 of the target host, iptables will translate the destination port to port 443 of the target. This is the command to append the rule to your iptables (for more info, see man iptables)

  iptables -t nat       \
           -A OUTPUT    \
           -d 10.0.0.1  \
           -p tcp       \
           -m tcp       \
           --dport 3872 \
           -j DNAT      \
           --to-destination 10.0.0.1:443

• The second iptables rule is defined on the target server. It says that every time there is an incoming tcp packet get from port 443 of the target, iptables translates the destination port to 3872 locally. This is the command to append the rule to your iptables:

  iptables -t nat        \
           -A PREROUTING \
           -d 10.0.0.1   \
           -p tcp        \
           -m tcp        \
           --dport 443   \
           -j REDIRECT   \
           --to-ports 3872

Once defined, the traffic from the OMS to the agent will go through port 443 even if none of the OMS or the agent actually know about this port. Note that while this method doesn’t require that you use HTTPS at all, you could use HTTP traffic via 443. Anyway, the second part of this post will explain how to make sure only HTTPS protocol is used even during the setup process, as it is not written in the documentation.

Part 2: Restrict the traffic to HTTPS

The restriction you have on the agent, you don’t have it on the OMS ! That’s because the OMS uses Apache and you can easily change Apache’s listening port to a port below 1024. You can refer to the Oracle HTTP server Administration Guide for more informations about how to setup Apache.

Once Apache is set up, you can change the listening port to 443 and restrict access to HTTPS only with the procedure described in “Enterprise Manager Advanced Configuration – 12.2 Reconfiguring the Oracle Management Service”. If you lock the OMS with the command below, you won’t be able to access it with any protocol other than HTTPS (you’ll be able to get the connection page but nothing more), no matter if the listening port is 443 or not.

$OMS_HOME/bin/emctl lock oms

Be careful — using HTTPS doesn’t mean you are using port 443.

So, once only HTTPS accesses to GridControl are authorized, install the agent with the method you prefer: agentDownload.sh, runInstaller silent or GUI based. You may even use the provisioning pack if you have SSH access to the box from the GridControl. You should be able to install and deploy the agent, but you won’t be able to secure it from the installation tools. That’s because those tools assume the first access to OMS is HTTP based and not HTTPS. To overcome this difficulty, you must manually secure the agent. Edit the emd.properties file located in $ORACLE_HOME/sysman/config or $ORACLE_HOME/`hostname`/sysman/config, depending if you run a cluster or not. Change the three HTTP URLs in it to HTTPS URLs, as described below:

1. REPOSITORY_URL should look like this: REPOSITORY_URL=https://oms:443/em/upload/. Change it to this: REPOSITORY_URL=https://oms:443/em/upload (REMOVE the / at the end and change the protocol to https.)
2. emdWalletSrcUrl should look like this: emdWalletSrcUrl=https://oms:443/em/wallets/emd. Change it to this: emdWalletSrcUrl=https://oms:443/em/wallets/emd
3. EMD_URL should look like this: EMD_URL=https://target:3872/emd/main Change it to this: EMD_URL=https://target:3872/emd/main

Once you’ve manually modified the configuration file, you can setup HTTPS (secure the agent), with the command below:

$AGENT_HOME/bin/emctl secure agent

That’s it! This way you won’t get any HTTP traffic between the agent and the OMS at all, no matter if you use 443 or another port. I think that’s almost all, expect a few other points:

• It took me a while to discover the problem with the / sign. I hope this one will be useful to somebody.
• If you want to thank anybody, this is the guy you should thank: Rusty Russell
• If, for some reasons you not only want to secure the agent, but also recreate its configuration, you may want to have a look at the command below. Note that this is an example of the emctl deploy agent command as used with with a clustered agent:

  emctl deploy agent \
        $AGENT_HOME/target \
        target:3872 \
        target

Grégory.

* In French: À la bite et au couteau!