RE: Keeping a DB from Phoning Home...

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Thu, 12 Sep 2013 12:14:49 -0400
Message-ID: <00f801ceafd3$35693290$a03b97b0$_at_rsiz.com>

If you cannot configure a firewall to isolate the particular appservers being used for the test to the dbserver, I suppose checking the contents of /etc/hosts and eliminating any host name matching there plus making sure the dbserver has no access to a dns server would be a pretty good start.

Can access the dbserver via direct logon? Someone has a console, right? I suppose then you could check the contents of sys.link$ and possibly TRASH any host strings you do not like, especially if the full ip address resolution appears there. If it is just server host names you can probably get by with just mapping all those to local loop back in /etc/hosts.

An actual firewall configured to prevent off campus traffic (where the campus is your allowed clients, your allowed app servers, and the dbserver) would be tightest, short of having all the pieces you need and none that you do not on a private Ethernet that simply does not have connections to the outside world.

mwf

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of David Mann
Sent: Thursday, September 12, 2013 11:07 AM To: oracle-l_at_freelists.org
Subject: Keeping a DB from Phoning Home...

I am helping a sysadmin archive a regulated system that is slated for retirement. Long story short is we have it up and running on a HP-UX emulator but have the network interfaces turned off. We also have some app servers that will be archived parallel to the server the DB is running on. The goal is to be able to turn on the network interfaces so we can access the DB with the app servers for some validation activities before the final archival... but we don't know the condition of the database, it is a total black box to us. We want to make sure it does not try to access any network resources like DB Links, sockets opened with Java, etc. as we are not sure what other internal systems it was communicating with when it was turned off.

The sysadmin currently has the DB running and all network interfaces turned off. I was thinking of starting the DB and using NetStat or whatever the HP-UX equivalent was but with interfaces turned off I don't think we would be able to observe any outgoing port activity.

So I get access to SQL*Plus on the console later this week. My plan so far is to check the following things before turning on the network interfaces and starting up the DB:

1. Set OPEN_LINKS to 0 to prevent attempts to open DB links.
2. Set JOB_QUEUES_PROCESSES to 0 - I don't have evidence that any jobs will cause something to initiate network access but want to cover the bases.
3. Check DBA_JAVA_POLICY for any Network/Socket related policies and investigate further if I find any.
4. ??? :)

After that I'm stumped. If you had a 9i DB that was a black box to you and were trying to ensure it was not going to try to initiate any outgoing activity when you started it up what would you do?

-Dave

--

Dave Mann
General Geekery | www.brainio.us
Database Geekery | www.ba6.us | _at_ba6dotus | http://www.ba6.us/rss.xml

--

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

--

http://www.freelists.org/webpage/oracle-l Received on Thu Sep 12 2013 - 18:14:49 CEST