Protecting Oracle Redo Transport

You can pay additional license payments to Oracle and have the Advanced Security Option take care of securing your Redo transport between your primary and your standby databases. However, alternatively, you could save yourself a good amount of license fees by using the open source OpenSSH to encrypt your redo traffic and use simple ssh port-forwarding.

Be aware that if you do not encrypt your redo transport then it is possible for your data to be read as it is sent over the wire. I looked at a tcpdump of the unencrypted traffic while I performed a simple update, and you can see both the original value and the updated value of the data. You really do not want to be sending this stuff if you have any sensitive data, but you can protect yourself easily.

First generate a public/private key pair for the oracle user:

oracle$ ssh-keygen -b 2048 -t dsa

Chose an empty passphrase when prompted.

Copy the public/private key to the standby server (you need a connection going in both directions, FAL is pull).

create your ssh tunnel:

oracle$ ssh -N -L 3333:remote-server:1521 oracle@standby-host

So port 3333 (you can choose your favourite number above 1024, that does not clash with some other service) is on the server that orginated the ssh tunnel, remote-server is the one you are connecting to (remember you want a tunnel going primary -> standby & standby -> primary) and 1521 is everyone’s favourite Oracle listener port. The -N flag means do not execute a remote command, while the -L specifies the localport:remotehost:remoteport that you want to use.

Now you create tns entries on primary and standby to use the port-forwarded connection:

(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 3333))

You now use this tns entry in your LOG_ARCHIVE_DEST parameter to direct your redo to the standby. Once this is done, no one can read your redo transport stream.

This also saves you having to open a hole in any firewalls to allow traffic on port 1521, as the traffic goes over port 22. I have used this trick not only for securing dataguard communications, but also for securing remote database logons for applications. I have seen no performance impact to this and to me it seems a whole lot simpler than the Advanced Security Option.


12 thoughts on “Protecting Oracle Redo Transport

  1. Hi Chris,

    yeah, with the tunnel you are no more impacted by network failure than pure tns, but yes you must start a failed tunnel or you will have a problem. I have found OpenSSH to be extremely reliable, though I do have a restart script to detect a tunnel failing and restart it, it’s fairly trivial to do in a few lines of bash.

  2. Howdy Laurent,

    You have 11 steps in your article, there is 3 in mine. Perhaps I am a lazy dba, but to my mind the less steps the less that can go wrong. Also does your configuration become dependent on the wallet manager running?
    I would also argue you are increasing the attack surface for any hacker by having to run more stuff. If i remember correctly in the October CPU there was a critical vulnerability that affected ASO – a larger attack surface means more potential intrusion points.
    We have ran with ssh tunnels for a number of years really without issue and they are extremely stable, oh and the overhead is minimal. ssh tunnels is supported, see metalink note 225633.1.
    I’d say use OpenSSH and use the license fees saved on ASO for active dataguard dataguard in 11g, such a shame all the cool new stuff is a cost option!

  3. If you have an in-house certication authority, you can skip step 1, 6, 7, 8 and 9.

    What’s more, your “security” design will allow not only TCP connection, but also password-less logging with SSH to the standby database. Anyone that access your private key will gain access to the standby server, which is something you should consider when using SAN or/and Filesystem Backups.

    Thank you very much for the metalink note. I am surprised !

  4. Yes, you must keep your private key private. I suppose you don’t have to generate a passphrase-less key, but this would make restarting your tunnel automatically should you need to a bit difficult. It’s not ideal, I grant you.

    The other option, that I should investigate is

  5. I don’t think that this does what you think it does.

    I am not any kind of security expert, but what you have done is secured the initial communication to the listener not the communication between the databases. Database traffic doesn’t actually use the listener port. A new port is picked for each session when it is established. So you have SSH on the initial contact, but not when the communication takes place.

  6. Hi Steven,

    What you say is not correct. All traffic using the above mechanism, all redo traffic is directed across the ssh tunnel. I’ll do a new blog posting showing the differences in protected and non-protected traffic.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s