Securing Database Links (DB Links)
Database links are a convenient way to access objects stored in another Oracle database. They simplify distributed queries, data integration, reporting, and replication.
From a security perspective, however, they deserve special attention.
A database link is more than just a connection between two databases. It often contains credentials that allow one database to authenticate automatically to another. If those credentials are overprivileged or poorly managed, a compromised database can become a stepping stone to other systems.
During security assessments, I regularly review database links before looking at application accounts. It’s not unusual to find links that point to production databases using highly privileged users or links that have not been used in years but still provide access to critical data.
In this article, we’ll learn how to inventory database links, identify risky configurations, and apply practical security recommendations.
Understanding Database Links
A database link allows one Oracle database to execute SQL statements against another Oracle database.
A simple query may look like this:
SELECT employee_id, first_name, last_name FROM employees@HRDB_LINK;
From the user’s perspective, it looks like a local table. Behind the scenes, Oracle establishes a remote session using the credentials stored in the database link.
This makes database links extremely powerful—and potentially dangerous.
Types of Database Links
Oracle supports several types of database links.
Private Database Link
A private database link belongs to a single schema.
Only the owner can use it.
Example:
CREATE DATABASE LINK hr_link CONNECT TO hr IDENTIFIED BY "password" USING 'HRDB';
This is generally the preferred option because access is limited.
Public Database Link
A public database link is available to every user in the database.
Example:
CREATE PUBLIC DATABASE LINK sales_link CONNECT TO sales IDENTIFIED BY "password" USING 'SALESDB';
Although convenient, public database links should be avoided whenever possible because they significantly increase the attack surface.
Connected User Database Link
Instead of storing credentials, Oracle uses the credentials of the currently connected user.
This approach reduces password management but requires the same user to exist in both databases.
Fixed User Database Link
The database link always connects with a predefined username and password.
This is the most common configuration and also the one that requires the greatest care.
Step 1 – Inventory Existing Database Links
Start by identifying every database link in the database.
SELECT owner, db_link, username, host FROM dba_db_links ORDER BY owner, db_link;
Example output:
| OWNER | DB_LINK | USERNAME | HOST |
|---|---|---|---|
| HR | HRDB_LINK | HR_APP | HRDB |
| PUBLIC | SALES_LINK | SALES | SALESDB |
| REPORT | REPORT_LINK | REPORT | REPORTDB |
Questions to ask:
- Is this database link still required?
- Does it connect to a production database?
- Does it use a dedicated account?
- Who owns it?
Every database link should have a documented business purpose.
Step 2 – Identify Public Database Links
Public database links are accessible to all users.
Review them carefully.
SELECT owner, db_link, username, host FROM dba_db_links WHERE owner = 'PUBLIC';
If the result contains several entries, review each one individually.
Many environments inherit public database links created years ago that are no longer required.
Whenever possible, replace them with private database links.
Step 3 – Review Remote Accounts
Pay close attention to the account used by each database link.
Example:
SELECT db_link, username FROM dba_db_links;
If you find accounts such as:
- SYS
- SYSTEM
- SYSBACKUP
- SYSDG
stop and investigate immediately.
Database links should use dedicated service accounts with the minimum privileges required.
A reporting database should never connect as SYS.
Step 4 – Review Remote Privileges
The account used by a database link should follow the same principle of least privilege as any local user.
For example:
A reporting application that only reads customer information should not have:
- CREATE TABLE
- DROP TABLE
- ALTER SYSTEM
- DBA
- SELECT ANY TABLE
Instead, grant access only to the required objects.
Example:
GRANT SELECT ON hr.employees TO reporting_user;
Avoid broad system privileges whenever possible.
Step 5 – Test Database Links
A database link that no longer works should either be repaired or removed.
Simple connectivity test:
SELECT * FROM dual@HRDB_LINK;
If the query fails, investigate:
- Listener availability
- TNS configuration
- Network connectivity
- Password expiration
- Service name changes
Broken database links often remain in production long after the remote database has been retired.
Step 6 – Identify Unused Database Links
Unfortunately, Oracle does not maintain a history showing when a database link was last used.
This means identifying unused links usually requires a combination of:
- Application review
- Job review
- Source code review
- Scheduler job analysis
- Developer confirmation
If no application or scheduled process depends on the link, consider removing it.
Step 7 – Remove Obsolete Database Links
Before dropping a database link:
- Confirm it is no longer used.
- Notify application owners.
- Test in a non-production environment.
Remove it:
DROP DATABASE LINK HRDB_LINK;
For public links:
DROP PUBLIC DATABASE LINK SALES_LINK;
Removing unnecessary database links reduces the attack surface and simplifies administration.
Step 8 – Avoid Embedded Passwords
One of the biggest weaknesses of fixed-user database links is the embedded password.
Instead of hardcoding passwords in scripts or repeatedly changing database links when passwords expire, consider using Oracle Secure External Password Store (SEPS) together with an Oracle Wallet where appropriate. This allows applications to authenticate without exposing passwords in scripts or connection strings.
Even when using SEPS, the remote account should still follow the principle of least privilege.
Step 9 – Protect Network Communication
A database link is still an Oracle Net connection.
If the remote database communicates across data centers or untrusted networks, ensure that the connection uses the secure Oracle Net configuration described in Part 3 of this series.
Review:
- Native Network Encryption
- TLS/TCPS (where applicable)
- Network integrity checks
Protecting the credentials is important, but protecting the network traffic is equally important.
Step 10 – Monitor Active Database Links
Oracle provides a dynamic performance view showing active database links.
SELECT db_link, owner_id, logged_on, open_cursors, in_transaction FROM v$dblink;
This view helps answer questions such as:
- Which database links are currently active?
- Is the remote session still connected?
- Are there open cursors?
- Is a distributed transaction in progress?
For day-to-day administration, V$DBLINK is often the quickest way to see active remote connections.
Security Checklist
Before moving to the next chapter, verify the following:
- Every database link has a documented business purpose.
- Public database links have been reviewed and minimized.
- Remote accounts use dedicated service accounts.
- Administrative accounts are not used by database links.
- Remote accounts follow the principle of least privilege.
- Obsolete database links have been removed.
- Network encryption is enabled for remote connections.
- Active database links are monitored when appropriate.
Common Mistakes
The following issues appear frequently during Oracle security reviews:
Using SYS in a Database Link
A database link should never authenticate as SYS.
Public Database Links Everywhere
Public links are convenient but often expose remote systems to unnecessary users.
Forgotten Database Links
Applications are retired, but the database links remain.
Every unused database link is an unnecessary security risk.
Overprivileged Remote Accounts
A reporting database does not need DBA privileges on the production database.
Password Changes Break Applications
Hardcoded credentials often cause unexpected outages after routine password rotations.
Plan password management carefully and test changes before deployment.
Conclusion
Database links are an essential feature for distributed Oracle environments, but they should be treated as privileged trust relationships rather than simple network connections.
Regular reviews of database links, remote accounts, and associated privileges help reduce the risk of lateral movement between databases. Keeping only the links you truly need—and ensuring they use dedicated, least-privileged accounts—goes a long way toward strengthening your Oracle security posture.
Google+
Facebook
