Oracle Database Discussions

Well, you need an open port to establish the communication to the database. 1521 is default, you can change that to something else, but then you will find the new port "open".

If the port is closed, no application would be able to connect to the database.

If you do have an Enterprise Edition database, you could hide your database behind a connection manager proxy and close the ports from all other hosts at your firewall.

Good afternoon,

As you told before, I have the same issue changing the port.

We don`t have enterprise and each customer has its own server with their databases, so I need a general workaround. In that scenario, customer manages his firewall, proxy... so I would like find out an Oracle solution.

I will wait and see if anyone can help.

Thanks a lot for your help.

Best regards.

As I said, you need open ports, otherwise the applications can't connect.

What do you want to see? That nmap tolds you, the port is closed? That will not happen - or the applications are "death"....

My fear is that through this kind of application (nmap shows port, Oracle version...), someone shows our version and knows its vulnerabilities, which could put the information at risk.

I want to avoid get this kind of information outside the server.

Connection Manager is distributed with the Oracle Client; it does not require Enterprise Edition to my knowledge. There's a paper here on how to configure it (written for 11g, but still works with 12c).

That said, from what perspective was nmap run? From a trusted host on the local network with the server, or from an external host outside of the server's "circle of trust"? In other words, what is an attacker most likely to see? This is about managing risk, so if the server's ports are generally protected by firewalls from outside access, then I wouldn't worry as much about nmap output from a trusted client. If the server is going to be exposed completely (BAD IDEA!), then I would configure the local OS firewall to block all traffic to that port except from trusted clients, like known application servers. In the end I think the only way to manage this is with a networking solution; I don't believe there's an option available in the Listener configuration to suppress that information from being returned.

One other thing: nmap and other scanners often leave distinctive traces in the listener logs. You should be monitoring for those in real-time as a counter-measure.

The specific vulnerability that you mentioned - CVE-2012-1675 - is mitigated through the use of Oracle's Valid Node Checking for Registration (VNCR), which is a configuration option in listener.ora. If you haven't already, you should check that out here:

Oracle Net 12c: Valid Node Checking For Registration (VNCR) (Doc ID 1600630.1)

Just note that this solution doesn't suppress the listener response to nmap, as you were asking about.

pmdba: From the 19c manual: "Oracle Connection Manager is available for installation with Oracle Database 12c Enterprise Edition. It is a custom installation option on the Client disk."

Sorry, but I do a lot of licensing things also

I think the OP does try to reach something that isn't possible without installing firewalls (even locally) and/or Connection Manager in addition.