In the past days I did lots of application protection planning with Oracle databases as backend.
Oracle SQL*Net encryption is an easy to implement measure for protection of the network traffic against sniffing attacks in a standard client-server application with an Oracle database as backend.
Why is encryption of the Oracle network traffic such important? Because everyone who can edit the sqlnet.ora configuration file is able to set up Oracle network tracing by adding just some configuration parameters.
With tracing enabled the entire session traffic, e.g. a change password command like
Alter user system identified by ",v$1ry c2mplex p$3ssword!";
is logged in plain text to the trace file. That’s extremely dangerous! Never change your password this way!
But the output of a standard SQL command like
Select employeeName, employeeSocialSecNumber from employees;
will be reported in plain text as well, even if column ’employeeSocialSecNumber’ is secured with Oracle Transparent Data Encryption option. Works as designed, transparent to the user. Even if the user takes care of the data the attacker with admin privileges could easily create a copy from the trace file.
With SQL*Net encryption activated the trace is no longer readable.
SQL*Net encryption is set up by just adding some configuration parameters to the sqlnet.ora file on the clients and the server. Thus everyone who is able to edit the sqlnet.ora file on the client could potentially disable encryption…
Fortunately parameter SQLNET.ENCRYPTION_SERVER set to REQUIRED on the database server controls session behaviour. A client connection attempt with session encryption disabled will be rejected with error message ORA-12260. Great!
But all server admins are able to edit this configuration file…
What can we learn from this?
Applying isolated security measures will not raise the overall security level.
The combination of security measures makes the difference!