Hello folks,
Do you know how is implemented one transparent proxy? How do it work?
Thanks,
Marcelo.
----------
> De: Litney, Tom <[EMAIL PROTECTED]>
> Para: '[EMAIL PROTECTED]'
> Assunto: Raptor Eagle SQLNET Proxy (or lack thereof)
> Data: Segunda-feira, 21 de Junho de 1999 18:31
>
>
> 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
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
