The following portion of the discussion pertaining to ports re. Oracle
is incorrect and will not work under any release of Oracle through any
firewall configured by a reasonably paranoid individual. I believe that
this is a reasonable assertion but leave it to the reader to decide: to
allow Oracle, the firewall allows (possibly a subset of) outside nodes
the ability to ORIGINATE connections to nearly-arbitrary unpriviledged
ports on the machine running the Oracle instance(s).
I guess we all want to sound like we are knowledgeable experts. My
reading of Allen's comments below suggest that he *assumes* he knows
what he is talking about without actually having that knowledge. I would
have stayed out of his well-intentioned distribution of misinformation
except that, when the reader finds out that one piece of information is
bogus, they might assume the second is as well. That assumption would be
unfortunate.
Please read the white paper/guideline from Oracle carefully, and have
your security administrator do so as well. Upon reading that paper, you
will understand that it is necessary to allow client connections inbound
to arbitrary unpriviledged ports on your Oracle server instance from at
least the range of IP's you need to connect with. If Allen's
instructions below were to work as stated, then you have some level of
security exposure and you need to consider the data sensitivity
carefully: your firewall is allowing unrestricted ORIGINATION of
connections from outside. Per the white paper, you can somewhat restrict
the range of ports, but not constrain them.
Regarding Allen's second statement about security: since you have to
allow unrestricted access on a range of ports, and since there is no
encryption (you have to move to Oracle 8 and Net*8 for that), there ARE
security issues. However, Oracle can be proxied (check with Oracle).
There is some level of 7.x (SQL*Net 2) support and "more better" Net*8.x
support. Several vendors are/were working to integrate Oracle proxy
support into their products ... but everything I do these days is
VPN'ed. In short, there are ways to work around the security exposure
that you understand exists.
One solution is an intermediate server running an Oracle instance on the
OUTSIDE (or on a suspect subnet/DMZ) with stored procedure based
filtering queries on "database links" (If you are a DBA you know what I
mean, if not please discuss the complexities of that solution with your
DBA as there are several). Your outside instance is sacrificial, and
should be assumed to be compromised from the instant it runs (so work
with your dba to deal with the password mechanisms and role permissions
accordingly). You would have to allow the above unpriviledged port
connections to it, then you can restrict the "real" Oracle server to
only allow connections from it.
Or you could use Sybase which considered the architectural need for this
capability 12 years ago and therefore doesn't have the problem. ;{)
Allen De Klerk wrote:
>
> Christopher
> What you should do is to take the info on exactly which ports you are
> using - 1521 or 1526 or other non-standard ports and have the firewall
> administrator temporarily open those ports for incoming and outgoing
> traffic.
>
> One important issue to consider is that this type of connection(from a
> security perspective) should in general NEVER be allowed.
>
> Regards
> Allen
>
> >>> Christoph Bamberger <[EMAIL PROTECTED]> 03/26 9:01 AM
> >>>
> Hi all,
> I'm trying to connect to an outside Oracle 7.3.2.3.0 database from a
> client behind my firewall (MS Proxy 1.0) but I just can't get SQL*Net
> to
> work.
>
> When testing the connection, I receive the following error message:
> ORA-12545: Connect failed because target host or object does not exist
>
> I have also contacted Oracle for information about this problem, but
> I
> didn't really understood what exactly I can do about that, since I'm
> not
> really a network expert. They said something about a port problem when
> the packets return from the db.
>
> So does anybody have an idea what I can do or is it simply impossible?
>
> thanks in advance,
> Chris
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
--
Daemeon Reiydelle
Systems Engineer, Anthropomorphics Inc.
[EMAIL PROTECTED]
(USA) 510-524-0310
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
