Re: DB link Secureness

For 100% clarity, DB link passwords can be read without much issue in an 11g database if you have the right privileges (default sysdba).

If you have privileges to export the DB link then you can import it wherever you want and grab the password from the database it was imported into. You want to treat your DB exports as secure as possible (you would be doing this anyway because data leaks are a serious problem).

As long as sysdba is only given to authorised people and as long as you’re not putting exports in insecure places then you should be okay. That said, there may well be privilege escalation vulnerabilities in your version of Oracle, there might even be in some of the code that you’ve manually deployed on top.

There’s not really a more secure replacement for DB links, if you need to use them then you’re going to have a hard time moving away.

Thanks,
Andy

On Sat, 19 Dec 2020 at 11:58, Lok P <loknath.73_at_gmail.com> wrote:

> Thank You.
>
> Actually even these are two different databases and both are prod say DB1
> and DB2 and are in the same network. The DB links of DB1 should not get
> simply imported to DB2 silently(with same credentials under the hood even
> if it's not exposed in EXPORT/IMPORT files) thus opening a window to access
> the REMOTE PRODDB (say DB3) which was initially meant for DB1
> users/applications only. Won't this be considered as a threat? Correct me
> if my understanding is wrong here.
>
> On Sat, Dec 19, 2020 at 11:56 AM Stefan Knecht <knecht.stefan_at_gmail.com>
> wrote:
>
>> Well, there's two sides to this.
>>
>> In any proper secured network, a DEV machine should not be able to
>> connect to a PROD machine. Be it via DB link or any other means. That's not
>> a database problem, that's a network zoning problem.
>>
>> But also, most places use post-import or post-restore steps which are
>> automatically or manually performed, to deal with anything left over that
>> shouldn't be the way the import creates them (e.g. you'd replace real world
>> user's emails with dummy emails when refreshing dev or qa with prod, and
>> you'd likely also want to change any passwords or database links
>> accordingly).
>>
>>
>>
>> On Sat, Dec 19, 2020 at 1:34 AM Lok P <loknath.73_at_gmail.com> wrote:
>>
>>> I checked two ways i.e first by taking the export dump and doing impdp
>>> with parameter SQLFILE and as I see in version 11.2.0.4 the dblink DDL is
>>> having a bind variable in place of password.
>>>
>>> Then I did try to see the .DMP file content and it's all junk. I didn't
>>> see any hashed value or bind value. So that looks perfect with respect to
>>> security stand point.
>>>
>>> Now one thing wanted to see, if somebody takes the export dump of dblink
>>> from PRODDB and import it in some Dev database say DEVDB , will that dblink
>>> will be created without any error? And in that case will the user silently
>>> able to connect to the REMOTEPROD using that dblink without anyone's
>>> notice? If it's true then even the password is not exposed to outside but
>>> still it's a security risk. Correct me if wrong?
>>>
>>> On Thu, 17 Dec 2020, 9:59 am Lok P, <loknath.73_at_gmail.com> wrote:
>>>
>>>> I am not very sure how to create DB links using TCPs and if it's the
>>>> safest with no security loophole. Can you explain a bit and we are on
>>>> 11.2.0.4 so if there is any version dependency?
>>>>
>>>> But the below doc does state that the password was stored as cleartxt
>>>> in sys.link$ in prior 10GR2. But nothing mentioned if export/import
>>>> password is exposing that in clear text in current versions or not?
>>>>
>>>> MOS Doc ID 202987.1
>>>>
>>>> On Thu, Dec 17, 2020 at 8:14 AM Mladen Gogala <gogala.mladen_at_gmail.com>
>>>> wrote:
>>>>
>>>>> Or create link using TCPS.
>>>>>
>>>>> On 12/16/20 2:03 PM, Powell, Mark wrote:
>>>>> > Ask the security team to present you proof the password can be
>>>>> exposed
>>>>> > when some exports/imports the link
>>>>>
>>>>> --
>>>>> Mladen Gogala
>>>>> Database Consultant
>>>>> http://mgogala.byethost5.com
>>>>>
>>>>> --
>>>>> http://www.freelists.org/webpage/oracle-l
>>>>>
>>>>>
>>>>>
>>
>> --
>> //
>> zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
>> Visit us at zztat.net | _at_zztat_oracle | fb.me/zztat | zztat.net/blog/
>>
>

--
http://www.freelists.org/webpage/oracle-l