Today I want to share with you one of my security projects which Iwas working on at DBConcepts GmbH.
One of the topics was the encryption of Oracle’s Network Traffic.
The purpose of a secure cryptosystem is to convert plaintext data into unintelligible ciphertext based on a key, in such a way that it is very hard (computationally infeasible) to convert ciphertext back into its corresponding plaintext without knowledge of the correct key.
The setup is as followed:
A high availablity setup using dataguard with a primary and standby database 19c EE Edition. Enterprise Manager Cloud Control 13c, a recovery catalog database and a application server corresponding to each database server are also in the IT Infrastructure and to be secured.
The task is as follows:
- the secure communication between the application server to the database server
- the encryption of Dataguard logshipping from the primary to the standby database
- the encryption of network traffic from the database hosts to the recovery catalog
- the encryption of JDBC-thin clients connecting to the database
I want to give you a quick overview about the possibilities which oracle offers and how unsecure a not encrypted communication is.
First, there are two encryption options which oracle provides:
- Oracle’s Native Network Encryption (using TCP Port 1521)
- TLS/SSL Encryption Standard (using custom TCPS Port f.e. 1522)
Oracle Database 19c supports the usage of a combination of those encryption options.
Let’s get into action:
I did a tcpdump from our monitoring host where an oracle client is installed to connect to a 19c database. It sends select statements to gather information for specific metrics.The tcpdump listens to all outgoing connections with the target database specified as the destination.
(Due to privacy policies hostnames and ip adresses are changed)
The result without a secure communication, which is the default setup for all database installations:
[root@<monitoring01> ~]# tcpdump -i eth0 dst <target db ip adress> -A -v
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
…
<start of packet>
11:12:34.455642 IP (tos 0x0, ttl 64, id 62432, offset 0, flags [DF], proto TCP (6), length 1161)
<monitoring01>.30585 > <target db ip adress>.ncube-lm: Flags [P.], cksum 0x5599 (incorrect -> 0xf31b), seq 1684:2793, ack 2135, win 501, options [nop,nop,TS val 3707091369 ecr 1327380418], length 1109
E.....@.@..p
3.
zjfwy... /9.&......U......
................................................................................................................................................@select replace(WAIT_CLASS,'/','') WAIT_CLASS,ROUND(FG,2) FG,ROUN@D(BG,2) FG_AND_BG,DBTIME,to_char(end_time,'yyyy-mm-dd hh24:mi:ss@') end_time from (
select sw.wait_class,wc.END_TIME, wc.WAIT_CLA@SS#, (wc.TIME_WAITED_FG)/(wc.INTSIZE_CSEC/1) fg, (wc.TIME_WAITED@)/(wc.INTSIZE_CSEC/1) bg, 0 dbtime
from V$WAITCLASSMETRIC WC,V$@SYSTEM_WAIT_CLASS SW
where WC.WAIT_CLASS#=SW.WAIT_CLASS#
and wai@t_class!='Idle'
union
select 'CPU',FG.END_TIME, -1, FG.value/100@, BG.value/100, DBTIME.value from V$SYSMETRIC FG, V$SYSMETRIC BG@, V$SYSMETRIC DBTIME
where BG.METRIC_NAME = 'Background CPU Usag@e Per Sec'
and BG.GROUP_ID = 2
and FG.METRIC_NAME = 'CPU Usage P@er Sec'
and FG.GROUP_ID = 2
and DBTIME.METRIC_NAME = 'Average Ac@tive Sessions'
and DBTIME.GROUP_ID = 2
and BG.END_TIME = FG.END_3TIME
and FG.END_TIME = DBTIME.END_TIME
order by 1)
.....................................................
<End of packet>
11:12:34.509827 IP (tos 0x0, ttl 64, id 62433, offset 0, flags [DF], proto TCP (6), length 52)
…v
As you see this is pretty scary. Every SQL-Statement and every response from the database is sent over the network in plaintext. In terms of privary and security Data modification attacks and replay attacks are possible.
Examples:
- Intercepting a $100 bank deposit, changing the amount to $10,000, and retransmitting the higher amount is a data modification attack.
- Repetitively retransmitting an entire set of valid data is a replay attack, such as intercepting a $100 bank withdrawal and retransmitting it ten times, thereby receiving $1,000.
This is were encryption comes to place to secure your company and enviroment against unauthorized parties intercepting data in transit.
After the implementation of security and encryption, this is the final result:
There is no plain text send over the network, only ciphertext !
[root@<monitoring01> ~]# tcpdump -i eth0 dst <target db ip adress> -A -v
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
<start of packet>
11:23:46.582209 IP (tos 0x0, ttl 64, id 3746, offset 0, flags [DF], proto TCP (6), length 696)
<monitoring01>.59236 > <target db ip adress>.ssh: Flags [P.], cksum 0x53c8 (incorrect -> 0xb685), seq 1633:2277, ack 3158, win 130, options [nop,nop,TS val 3707763496 ecr 1328052548], length 644
E.....@.@...
3.
zjf.d..............S......
...(O(yD...U
J3R.Ok.J._.W/....ZpZ
*.:/..d.#.......Bl.&.Z5a.3.....B.....m.S....U..NtS.......y..x......*>.b....$...^ij........Z6..KPK......~v\.WvHm.6.$&9.%;.x..x#a.:..5.... .X=[M...?......xv3i&(.|.-+.p.~.n...i.J.wW...qS"d....Z...........eY1.L..V..F5..(..E.O...'.os.
Y.xIG8......K....5rh.F@..D=..~............].U.Fi..7.u......e..y/..C'..... |...{o_..6b>`..}.X.f...H..K=`v.>
.....i.....B ..d*os.h&.....:....W.G....C.s...2.V..HWA(o..e ....$x.....|. ....Kwz.....:p.Nz.Aqz..5..+V+dtria..lv7T..k.n..5E.....
<end of packet>
11:23:46.582899
…v
Hardening the systems and implementing security features is a must !
to be continued …
