gary flynn <gary @
habanero .
jmu .
edu> asks about some assumptions:
> 1. Unlike a non-transparent firewall which requires a direct connection
> request to the firewall and/or proxy software on the client to
> support an authentication conversation, transparent application
> firewalls can't do authentication. If authentication is desired,
> transparency is lost by definition and, with it, the ability to
> use standard client software and procedures.
The impending Sidewinder release provides both the transparent proxy and
firewall authentication for Telnet. It uses the standard Telnet client
but it requires an additional login procedure to get through the firewall.
This only affects the procedure a user must perform in order to access
external hosts. Essentially the site has to trade off the higher
degree of access control over the costs of training and user
permission management.
An alternative that many sites use with the current Sidewinder release
is to establish access control permissions to proxies on individual IP
addresses. This retains transparency while providing some measure of
access control to external systems, and it works with all proxies.
> 2. The proxy applications are fairly complex and proprietary depending upon
> level of filtering and logging (address, port, operation, application
> information such as file names transferred, mail IDs, URL access, ftp
> and telnet userIDs, SQLnet database fields accessed, etc.)
It's not in the proxy code; the changes are made to the networking
infrastructure. On Sidewinder we combined the task with the work of
separating the TCP/IP stacks out so we have independent stacks for
each network interface. We then use Type Enforcement to ensure that
behavior of one stack can not interfere with the other. Thus, failure
in the network code on the Internet side won't yield access to the
internal network.
Access control and logging is implemented at the network level so that
it applies consitently to all proxy services. We don't have to write
elaborate proxies. The structure is engineered so that we can port
public domain proxies when we want to provide a more sophisticated
service, like the CERN HTTP proxy. Or you can instantiate "generic"
proxies associated with specific port numbers that act like
transparent circuit gateways.
> 3 and 4
Generally true statements.
> I didn't see a lot of information on transparent proxys in either
> "Firewalls and Internet Security" or "Building Internet Firewalls".
This shows how quickly the concepts are evolving.
An interesting wrinkle on transparent proxies: consider how they act
within a site that had never before been on the Internet and that
arbitrarily assigned itself some of the Internet address space. If
someone in the site tries to connect to an Internet server whose
address has already been used within the site, the user gets the
internal host, not the external server. Another good reason for Net
10 if you can't get the numbers you need.
Rick.
smith @
sctc .
com secure computing corporation
|
|
