Shared drives through a firewall

Hello Group;

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?

Big Thanks if you can

Eigen

Drive mapping isn't guaranteed to use NetBIOS - this depends
on the OS
and revision.
For instance, Windows began using SMB (TCP:445) on Windows
2000 and
later for remote file shares (although NetBIOS connections
are still
supported for downlevel compatibility.
The problem with allowing either or (FSM help us) both
across one; much
less two firewalls is that file shares aren't the only
things that use
these transports.
Remote registry, remote service control are two of my
favorite examples
of SMB-carried traffic.

My favorite p1553d-0ff domain admin trick is:
for %i in (list of dcs) do sc \%i config netlogon start=
disabled & sc
\%i stop netlogon

You won't reverse this action without a recovery console,
since the DCs
in question can no longer authenticate any logon attempt. 
Of course,
you have to order your list properly so as to do the GCs
last, but for a
domain admin, that's trivial info gathering.

The point is; if you allow direct file share access between
your
security zones (or else why have a firewall between them),
you create a
much larger threat than simple file mangling.

You might consider using FTPS or SSH connections; they're
relatively
secure, depending on the server/client package you select.

Jim

-----Original Message-----
From: listbouncesecurityfocus.com [mailto:listbouncesecurityfocus.com]
On Behalf Of aehealdgmail.com
Sent: Wednesday, March 21, 2007 7:01 PM
To: focus-mssecurityfocus.com
Subject: Shared drives through a firewall

Hello Group;

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?

Big Thanks if you can

Eigen

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

It's not that fool, you know 
Depending on what OS you want to try this, you can use the
SMB protocol 
with an encrypted layer.
SMB can be used on Windows/*nix systems.
A good point to start is to read this text which tells how
to add the 
crypted layer to the SMB protocol :
http://home.a
rcor.de/36bit/encrypt.html

Good luck!
Nicolas


aehealdgmail.com a écrit :
> Hello Group;
>
> 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?
>
> Big Thanks if you can
>
> Eigen
>
> .
>
>   

Seems to me, if the client is willing to do it you can't
really call it
an "untrusted server."  Foolishly trusted
maybe...

I'm also confused that if I have to go through two firewalls
to get to
it, how can it be considered to be in a DMZ?  Unless you're
client is
running two firewalls, to which I'd have to ask, why?  Two
is no better
than one once a port is open on both.

That aside, I'd think you have to learn more about this
other server to
properly analyze the risk.  Is it truly in a DMZ or is
netbios only open
to IP addresses/ranges of it clients?  Does it support,
better yet,
require SMB signing?



> -----Original Message-----
> From: listbouncesecurityfocus.com
> [mailto:listbouncesecurityfocus.com] On Behalf Of
aehealdgmail.com
> Sent: Wednesday, March 21, 2007 10:01 PM
> To: focus-mssecurityfocus.com
> Subject: Shared drives through a firewall
> 
> Hello Group;
> 
> 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?
> 
> Big Thanks if you can
> 
> Eigen

Jim Harrison wrote:
> You might consider using FTPS or SSH connections;
they're relatively
> secure, depending on the server/client package you
select.

Webdav is under-promoted in these scenarios - it's built on
top of a 
well-understood and easily securable protocol (http), and it
has great 
crossplatform support. Webdav allows access either via a
webdav client 
that supports writing (windows explorer and gnome/nautilus
both do this, 
and OSX/KDE/$desktopofchoice probably do too) or a standard
http client 
(ie, lynx, firefox). It supports well-understood mechanisms
to encrypt 
traffic (TLS/SSL) and authenticate users (http basic auth).

It has good application layer support from a wide variety of
reverse 
proxy/firewall products (including ISA) designed for
protecting web 
traffic if you choose to expose it externally.

It's also fairly difficult to distinguish from a regular
webserver, so 
it's far less likely to draw attention from attackers than
opening up 
SMB ports, particularly if you had a webserver running
anyway.

There's also been webdav support in IIS and in Apache for
quite some time...

  - James.

-- 
   James (njan) Eaton-Lee | UIN: 10807960 | http://www.jeremiad.org

   "The universe is run by the complex interweaving of
three
   elements: Energy, matter, and enlightened
self-interest." - G'Kar

  https://www.bsrf.org.uk |
ca: https://www.cac
ert.org/index.php?id=3
-- 

True SSH and WebDAV are better options, but that's changing
the topic.
I'm guess since it's an "untrusted server" that
someone else is
administering it.  So using a different protocol probably
isn't an
option.

As far as being less likely to draw attention from attackers
than
opening up SMB ports, the key here is to only open SMB ports
to allow
communication between the server and client.  Don't just
open SMB ports
to the world because you need to communicate with one IP
address on the
other side of your firewall.  That's as silly as opening all
ports on a
server, just because you need one open.



> -----Original Message-----
> From: listbouncesecurityfocus.com
> [mailto:listbouncesecurityfocus.com] On Behalf Of James
(njan) Eaton-
> Lee
> Sent: Thursday, March 22, 2007 1:15 PM
> To: Jim Harrison
> Cc: aehealdgmail.com; focus-mssecurityfocus.com
> Subject: Re: Shared drives through a firewall
> 
> 
> Jim Harrison wrote:
> > You might consider using FTPS or SSH connections;
they're relatively
> > secure, depending on the server/client package you
select.
> 
> Webdav is under-promoted in these scenarios - it's
built on top of a
> well-understood and easily securable protocol (http),
and it has great
> crossplatform support. Webdav allows access either via
a webdav client
> that supports writing (windows explorer and
gnome/nautilus both do
> this,
> and OSX/KDE/$desktopofchoice probably do too) or a
standard http
client
> (ie, lynx, firefox). It supports well-understood
mechanisms to encrypt
> traffic (TLS/SSL) and authenticate users (http basic
auth).
> 
> It has good application layer support from a wide
variety of reverse
> proxy/firewall products (including ISA) designed for
protecting web
> traffic if you choose to expose it externally.
> 
> It's also fairly difficult to distinguish from a
regular webserver, so
> it's far less likely to draw attention from attackers
than opening up
> SMB ports, particularly if you had a webserver running
anyway.
> 
> There's also been webdav support in IIS and in Apache
for quite some
> time...
> 
>   - James.
> 
> --
>    James (njan) Eaton-Lee | UIN: 10807960 | http://www.jeremiad.org
> 
>    "The universe is run by the complex
interweaving of three
>    elements: Energy, matter, and enlightened
self-interest." - G'Kar
> 
>   https://www.bsrf.org.uk |
ca: https://www.cac
ert.org/index.php?id=3
> --

mcclenbwoneonta.edu wrote:
> True SSH and WebDAV are better options, but that's
changing the topic.
> I'm guess since it's an "untrusted server"
that someone else is
> administering it.  So using a different protocol
probably isn't an
> option.

Maybe.. sometimes the best solution to an awkward problem is
to rewrite 
the problem. The OP did ask for "ammunition", too
- an easy, securer 
alternative way of transferring files certainly seems like 
anti-SMB-over-the-internet ammunition to me! 

I've had success in rewriting the problem such that I could
deploy 
webdav on a number of occasions in the past where SMB or FTP
were being 
considered for file transfer.

It sells quite well in this respect based on the fact that
it has great 
client support (better than SCP/SFTP) and in both the linux
and windows 
worlds very rarely requires any extra software for anyone
who already 
has any web infrastructure in place. At worst, the extra
software is an 
apache module..

> As far as being less likely to draw attention from
attackers than
> opening up SMB ports, the key here is to only open SMB
ports to allow
> communication between the server and client.  Don't
just open SMB ports
> to the world because you need to communicate with one
IP address on the
> other side of your firewall.  That's as silly as
opening all ports on a
> server, just because you need one open.

Agreed - but in most scenarios, opening up SMB, even to
quasi-trusted 
partners or clients over a WAN isn't ideal either way; too
many holes 
that go too deep for my liking, and they're holes that
(unlike 
HTTP(s)/Webdav) generally can't be partially mitigated with

application-layer filtering.

The addition of IP / IP Range filtering makes this scenario
less awful, 
but not unawful, imo. 

  - James.

-- 
   James (njan) Eaton-Lee | UIN: 10807960 | http://www.jeremiad.org

   "The universe is run by the complex interweaving of
three
   elements: Energy, matter, and enlightened
self-interest." - G'Kar

  https://www.bsrf.org.uk |
ca: https://www.cac
ert.org/index.php?id=3
-- 

> 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

"..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: listbouncesecurityfocus.com [mailto:listbouncesecurityfocus.com]
On Behalf Of Nicolas RUFF
Sent: Tuesday, April 17, 2007 1:54 AM
To: aehealdgmail.com
Cc: focus-mssecurityfocus.com
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.