Re: Re: DB link Secureness

From: Powell, Mark <>
Date: Wed, 16 Dec 2020 19:03:33 +0000
Message-ID: <>

Ask the security team to present you proof the password can be exposed when some exports/imports the link.

Mark Powell
Database Administration
(313) 592-5148

From: <> on behalf of Lok P <> Sent: Wednesday, December 16, 2020 12:51 PM To: Matthias Rogel <>
Cc: <>; Oracle L <> Subject: Re: Re: DB link Secureness

Another point is, we have been using many DB links across multiple databases since the past. And the db version is And just got to know from the security team to get rid of these DB links in the long term because the password can be exposed when somebody exports/imports the DB link. So want to know from experts , if it's really a concern and we should get rid of all the DB links?

When i tried seeing the DDL in toad , I see as below which is again its showing the field as "<password>" and not showing the exact clear text in DDL script though. So a bit confused. Also not finding anything clear in Oracle doc.


 USING 'PROD1'; On Sat, Dec 12, 2020 at 12:56 AM Lok P <<>> wrote: Thank you very much. I will check again if we are supposed to cater the security issue for specific schema only and then that we can think of schema based trigger rather a database trigger.

I am still trying to understand how the hostname can be spoofed which will then create another break for us. And this solution may not help us then.

On Thu, 10 Dec 2020, 11:14 pm Matthias Rogel, <<>> wrote: It will not block SYS from logging on
Am 10.12.20, 18:39 schrieb Lok P <<>>:

Do you mean to say , if we create this database level trigger and this table gets truncated then the first condition(Safe_host IS NULL ) in the trigger code will always be satisfied and thus will not let any user to login into the database? Will it also block the DBA to login too from SYS and thus can halt all DB operations and thus we should never create such database logon triggers?

On Thu, Dec 10, 2020 at 9:10 PM Rich J <<>> wrote: You might want to consider creating multiple triggers on just the schemas needing to be audited/secured. If someone were to accidentally delete/truncate that security table, well, it would be bad. I would always have at least one way into the database that didn't rely on that trigger firing.

My $.02,

On Thu, Dec 10, 2020 at 9:07 AM Lok P <<>> wrote:

Hi, we are on the version of Oracle. I have been a bit confused about working on the public VS private DB links. But recently, we have a security audit requirement in which it's required to block the login of users from other hosts except the defined ones through the DB link user login account. Team is coming up with the below trigger to handle this, for which we will insert all possible legitimate "HOST Name" and "DB link username" entries manually in a table "DB_LINK_USERS", and then below trigger will ensure the login from valid hosts.

We are trying to understand if this solution is okay considering it will be fired in each and every login and if it will have any significant performance overhead. Or any other way we should cater this need?


Received on Wed Dec 16 2020 - 20:03:33 CET

Original text of this message