Conference noted::seal

What advantages are a Netbios proxy going to give you over a screend filter?

Before anyone can attempt to provide a solution, you have to define an 
"acceptable level of risk".

PJDM

re: .1

Let me give you some background regarding our situation.  Our requirement is to
remotely manage multivendor customer systems (hostile) from our Command Center
(trusted).  Currently, we are using a firewall and personal tunnels as tools to
accommodate system connectivity.  However, the tunnels expose our inside IP
addresses to the hostile side.  We are using tunnels specifically for NT
connectivity because NetBIOS requires three ports (137/UDP,138/UDP,139/TCP).
Thus, in our configuration, the firewall serves to force inbound NetBIOS
packets down a personal tunnel. 

>> The Problem with Screend

To enable NT system(s) on the inside of a firewall to map to NetBIOS share
points on NT system(s) outside the firewall, NetBIOS ports must be opened up
bi-directionally within screend for this to work over IP. When you run
NetBIOS-over-IP, you have now opened up all your print, file, and application
sharing services to these inside system(s). Moreover, a hacker can fake a
NetBIOS-over-IP session and try to penetrate ANY SYSTEM on the inside.  The
use of the nbtstat utility is especially useful to a hacker for this type of
attack thus resulting in an "unacceptable level of risk"!. 

>> Advantages of a NetBIOS Proxy

There would be a number of advantages to using a NetBIOS Proxy:

1) NetBIOS packets would not have to pass directly between the inside 
and outside NT systems.

2) A NetBIOS proxy would log only NetBIOS activity which results in a 
much smaller and useful log.

3) A NetBIOS proxy would prevent a hacker from penetrating a personal tunnel
NT system on the inside.

>> What Constitutes an "Acceptable Level of Risk?"

This means that any NT outbound initiated connection (inside to outside) is
allowed.  If a corresponding outbound to inbound response is other than
an acknowledgment, then this inbound connection is allowed.

If we had a NetBIOS-over-IP proxy resident on a firewall, that would constitute
an "acceptable level of risk" for our customers.

You _MAY_ find that the UDP relay and the new TCP relay, when they arrive, 
will be able to handle this situation.  Wait a few weeks, and we'll all find out ...

T

Some (most?) routers can be configured such that outbound initiated connections 
are allowed, but inbound initiated connections aren't. (Cisco and Xyplex can do 
this.) That might help a bit.

A quick look through the screend man page doesn't expose the same functionality, 
though.

If you combine screend with the tunnel, then you can restrict tunnel sessions to 
go only to one internal system. You'll still have to watch that system, of 
course.

A NetBIOS proxy (as opposed to a generic TCP/UDP proxy) would certainly be 
useful here. An AltaVista search for "netbios proxy" turned up the following at 
http://www.bredex.de/EN/bredex/infos/security/V5.4/msg02262.html:

Subject: Netbios proxy 
From: Wendy Hedgpeth <[email protected]> 
Date: Wed, 4 Dec 1996 07:42:26 -0800 

Does anyone know of a firewall package that has a netbios proxy?  Please
reply directly to me.  I am not on this alias.
thanks,
Wendy Hedgpeth
Microsoft Premier
technical account manager
[email protected]
(704)-582-8522

When a Microsoft technical account manager doesn't know where to find one...

PJDM

    Hello,
    
       The screend version which is available and maintained in the
    public domain (available at ftp://ftp.vix.com/pub/vixie)
    supports TCP bit clauses in the screend.conf rules.
    
       I have tested once that it compiles fine on Digital UNIX
    (a bit of makefile and include file twiddling as always, but nothing
    dramatic), and that the feature works.
    
       Of course, that screend does not include the Altavista hacks,
    so you may not want to run that on an AVFU, unless you're
    willing to give up certain features (such as transparent proxies
    and maybe more than that)...
    
       Regards,
       Marc Chatel @ AEO
       

    We discovered today that the Start-of-Connection packet filter
    (as defined in topic #1829.0 of this conference) allows a Windows 95/NT
    client (inside Firewall) to connect to a NetBIOS-over-IP share on a
    Windows NT Server (outside Firewall) through an AltaVista Digital UNIX
    Firewall.
    
    However, we could NOT connect to a NetBIOS-over-IP share on a PATHWORKS
    OpenVMS Server because the server requires an inbound initiated
    connection to port 139/TCP on the client instead of an ACK.
    
    Is the new TCP relay mentioned in .3 designed to address this
    problem in a multiple Windows 95/NT client to multiple PATHWORKS OpenVMS
    Server NetBIOS-over-IP scenario?
    
    Please advise.
    
    			\Thanks in Advance
    
    P.S.: Also found out that Raptor has a NetBIOS-over-IP relay for their
    Windows NT Firewall implementation subject to certain restrictions. 
    Their web site at www.raptor.com has detailed information regarding this
    relay in their FAQ section.

Are you saying that the communication to a VMS PATHWORKS Server
is that the client (PC) requests on UDP and the Server opens a
reverse TCP connection?  If so, then the generic relays will
never be able to handle this, just as they can't handle FTP - it
exactly the same problem with both protocols, if my understanding
of what you're saying is correct.

Why is it different between different servers?  Any ideas?  Is it
a version difference?

... and finally, I would almost (99.99999%) bet that Raptor's 
netbios-over-IP relay can't handle the VMS case, either ...

T

    re: 7
    
    Yes, the server opens a reverse TCP connection back to the client which
    is prevented by the Start-of-Connection packet filter screening rules.
    
    I don't have a clue as to why the difference between the
    NetBIOS-over-IP NT vs.PATHWORKS protocol behavior.
    
    I have posted this problem in the NOTED::PWDOSWINV5 conference topic
    #7347 to see if someone there can shed any light on this discrepancy.
    
    			\Thanks in Advance

    re: .8
    
    Phil Wells, PATHWORKS architect, provides the following explanation
    below for the back connect reason.
    
    As Phil suggests, is there any way for an AltaVista UNIX/NT firewall to
    allow a back connect to port 139 but ONLY to a fixed NetBIOS name?
    
    Please advise.
    
    			\Thanks in Advance
    
              <<< NOTED::NOTES$9:[NOTES$LIBRARY]PWV50IFT.NOTE;1 >>>
                 -< PATHWORKS V5.0x for OpenVMS (LAN Manager) >-
================================================================================
Note 4196.1            Firewalling NetBIOS-over-IP Problem                1 of 1
CPEEDY::wells.lkg.dec.com::wells "Phil Wells"        14 lines  13-MAR-1997 14:07
                           -< it's a license probe >-
--------------------------------------------------------------------------------
The PATHWORKS server (and the license server, but that's a different 
questions) probe the client for a license after the first 
protocol message (SmbNegProt).

If the client doesn't have a license (or if the connect fails, etc.) 
then the PW License Registrar allocates a server based license.

So, if the PW server had some server based licenses available, I 
think you would have been able to connect.

Back connects are also to port 139 and to a fixed NetBIOS name.  How 
intelligent is this filter?

Phil

re: .9

PATHWORKS for OpenVMS Engineering informed me today that a blocked back-connect 
to port 139/tcp on the Windows NT/95 client will cause the PATHWORKS License 
Server to allocate a PATHWORKS Concurrent Use license for the Windows 
Nt/95 client.  However, the PATHWORKS for OpenVMS Server must be at 
revision 5.0d-EC02 or above for this functionality to work.

I tested this assertion with a PATHWORKS for OpenVMS Server V5.1 system 
and it works!