On Tue, 16 Jul 1996, Greg Otto wrote:
> Also, how would one go about doing outbound traffic through a proxy
> type firewall.
I've written about this on the firewalls mailing list before, I think.
Basically, you can use a plug-board proxy (plug-gw from fwtk, e.g.), to
proxy 139/tcp through the firewall to your destination machine.
Unfortunately, given the dumb nature of a generic tcp proxy, you can only
connect to one outside system from a given inside system.
If that will meet your needs, the challenge is getting the internal client
to connect to the proxying firewall when you want to connect to the
external system. I accomplished this by putting the firewall's internal
IP address on the external system's name in the LMHOSTS file. I.e., make
the internal client think that the firewall _is_ the external server. You
might be able to play similar games with WINS, though I've not tried it.
You need to have the client think it's really connecting to the external
server because the SMB connection protocol includes the server's name. NT
servers (in my experience) will reject a connection if the name in the
connection message does not match its own sense of itself.
The Samba Unix client for sharing files with NT (and other MS) clients is
not so picky. If it gets a connection request for a share or a service
it's offering from an authenticated user, it doesn't care what the host
name in the connection request is. When going through a firewall to a
Samba server from an NT workstation, I just made the connection to
"\\firewall\sharename", e.g., and got a good connection to the Samba
server on the outside.
Given that the hostname of the server is contained in the connection
request, it ought to be possible to write an SMB-specific proxy that would
read the hostname in the connection request it's proxying to determine
where to make the end connection. It could then be configured to allow or
deny any combination of clients and servers. I'm unaware of any such
proxy. You'd still have to trick the client to make the connection to the
firewall, unless you were using transparent proxy technology as
implemented in certain commercial proxying firewalls.
WARNING: It appears to me through experiments I've conducted that NT wants
the entire connection request in a single packet, entirely contrary to the
streaming nature of TCP. When testing with a proxy that reencapsulated
the data into smaller IP packets, the NT server read the first packet,
recognized it as the beginning of an incomplete connection request, and
sent back an error before reading the 2nd packet containing the remainder
of the connection request.
This must be an error; TCP is a streaming protocol and how the data is
delivered between multiple packets should be irrelevant to a correctly
written application. Interestingly enough, the Unix Samba package worked
properly through this same proxy. It's easy to visualize a programming
error that causes the improper behavour I've seen with NT. (No, I don't
recall the exact release and serivice pack numbers on the NT system on
which I've observed this.)
One security advantage of proxies over packet filters is that the proxy
re-encapsulates the data into new packets, so no IP options,
fragmentations, etc., on the incoming stream's packets appear on the
outbound side. As TCP is a streaming protocol without any message
boundaries being needed by or available to the applications, it shouldn't
matter whether or not the proxy sends the data in the same number of
packets of the same size as on its receiving side.
Russ Cooper (I think) sent me some configuration suggestions to try on the
NT system to see if it could be make to behave properly in this scenario,
but I've never had a chance to try them and see if it helps. I'm sure I
have his message around here somewhere, but I cannot find it right now.
If he sees this, perhaps he'll repeat it to the list.
-- KH
References:
|
|
