Raptor Eagle SQLNET Proxy (or lack thereof)

["Litney, Tom" <TLitney () caiso com>]

  Those of y'all who know me, know that I have been around for a while.  You
also know that I never take part in religious wars, or vendor bashing or
sniping.  I don't want this message to be construed as any of the above.  I
do feel obligated to report the results of our experience with the Raptor
Eagle firewall regarding its so-called sqlnet proxy.  I will not go into the
time to market issues for our internet commerce applications that required
us to purchase firewalls relying on vendor hype and not on complete testing
in our lab.  And I will not describe our internet commerce design in any
great detail.  We do have a design which includes a web server, an
application server, and a database server.   Because of performance
requirements for Oracle database replication and business resumption
concerns, the database is not co-located with the application server.
Instead it is located in our database "farm" which is serviced by our OC12
links for performance.  In the interest of security I wanted a proxy
firewall to handle the sqlnet calls from our application server to the
database.  I settled on the Raptor because the marketing hype promoted a
sqlnet proxy.  We have Oracle set up with a listener on the database server
which receives sqlnet calls.  The application checks to see if the listener
is "alive" to determine if the database is accessable.  If the listener does
not respond, the application has a table of alternate databases which it
uses to connect to the backup servers.  I believe that this is a fairly
normal Oracle database setup.  Now we configure and stick a Raptor in the
mix.  The Raptor successfully dealt with the sqlnet calls to the primary
database in normal operation.  However, when we tested the failover scenario
the Raptor was unsuccessful.  This was because the Raptor intercepted the
"alive" checks targeted for the Oracle listener and responded successfully
on the listeners behalf (and isn't that exactly what a proxy is supposed to
do:-) ).  Unfortunately, when the listener was actually down and not
responding, the Raptor did not pass the expected message back to the
application server.  So the application was never aware of the situation and
did not switch to the backup server.  We called Axent regarding this
situation.  I talked to Guy who was their expert in the area.  To his credit
Guy was knowledgeable, helpful and sympathetic.  He offered some suggestions
for a get around, none of which were applicable in our environment.  The
first was to trick it by using DNS and defining several entries with the
same host name and different IP addresses.  So if the primary server was
down we would get the backup.  This would not work in our case for several
reasons.  The primary one being that the database does not exists as the
sole entity on the server and I can't down a server just because one
database fails.  The second idea was to disable the sqlnet proxy and create
a local tunnel thereby turning the proxy into an SPF (a somewhat expensive
SPF at that).  There were also reasons that this didn't work because of some
of the nat'ing that we were doing and besides this solution just didn't sit
well with me.  Had I wanted an SPF (and we do have many) I would have
designed it in at the beginning.   I ended up having to remove the Raptor
from the design and suffered a bit professionally from the whole experience.

    I don't think that our situation is unique and I wanted to warn folks to
be cautious if they are considering the Raptor for its ability to proxy
sqlnet traffic.  Unless you have a primary server which never goes down and
a listener which is always available, or you can do a manual change to your
application server when they do fail, you may have a spot of trouble.  And
for us this is just not "real world".  IMHO the Raptor sqlnet proxy is
marketing hype, because the ability to automagically failover to an
alternate database is surely required for any "real" production
implementation.  Axent is working with Oracle on the "second generation"
sqlnet proxy but Guy admitted he did not expect it anytime soon.  By the
way, if you see me standing by the side of the road with a sign reading
"security engineer, will work for food" be sure and beep.


Note: The previous information are my own opinions and not to be construed
as those of my employer.


Tom Litney
Senior Security Architect/Engineer
CAISO