"..it will just fail.." - sorry, this is only conditionally true.

While it's true that these protocols (like many others) were not
designed with NAT in mind, the protocols themselves generally operate
just fine through a "transparent" NAT device. There are three general
cases where file share access will have problems through NAT:
1. the NAT device tries to be "smart" about such protocols and actually
trashes the traffic in some form (try chasing that down!)
2. SMB signing is employed between the two hosts. Be careful about
disabling this; http://support.microsoft.com/kb/839499
3. the NAT is "cone" (most are) and more than one internal host is
attempting to access the SMB-based file share simultaneously
(http://support.microsoft.com/kb/301673).

I do agree that providing direct SMB or NetBIOS access across your
traffic security boundaries is asking for huge trouble.

Jim

-----Original Message-----
From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]]
On Behalf Of Nicolas RUFF
Sent: Tuesday, April 17, 2007 1:54 AM
To: aeheald (at) gmail (dot) com [email concealed]
Cc: focus-ms (at) securityfocus (dot) com [email concealed]
Subject: Re: Shared drives through a firewall

> I am trying to persuade a client NOT to map a drive through two
firewalls to
> an untrusted server in a DMZ to run an application. I've tried
Googling
> Netbios and security, but get so many entries as to be useless.
> Other than the latency issues, and my ten cents that it seems to me to
be an
> enormously foolish idea, can you folks offer me any further
ammunition?

Here is your silver bullet: it won't work :)

The SMB+NetBIOS+TCP/139 protocol is not NAT aware.

So unless your client is using public IP addresses internally, it will
just fail.

Regards,
- Nicolas RUFF

All mail to and from this domain is GFI-scanned.

[ reply ]