RE: Keeping a DB from Phoning Home...
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <dmann99@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 12 Sep 2013 12:14:49 -0400
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of David Mann
Sent: Thursday, September 12, 2013 11:07 AM
To: oracle-l@xxxxxxxxxxxxx
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 | @ba6dotus | http://www.ba6.us/rss.xml
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
