Home Storage Area Network security

Mailman List Mirror (Read Only)
1

I received a few comments about file servers not serving files by default.

There are a bunch of home SAN products on the market. They are designed
to make it very easy for customers to set up and use a home storage area
network.

I think these are very cool products, and although some geeks like
building stuff from scratch, other folks like buying stuff assembled and
working out of the box. But they seem very dangerous when connected
directly to the open Internet without some access control turned on.
Instead they "assume" there will always be a secure firewall in place,
protecting the devices.

But in all the discussion about how secure their products are, you rarely
see an explicit requirement for these SAN devices to be installed behind
a firewall. Just because you use Linux does not make SMB secure on the
Internet.

http://www.mirra.com/
Ease of Use: Just plug in Mirra, run the installer, and let it auto-detect
your network settings. Name your Mirra, say .ok. to the recommended backup
set (or select your own), then forget it. Remote access is simple to use
as well. No IPs to configure, no firewalls to penetrate. Mirra does it for
you.

http://www.martian.com/howtouseit.html
The NetDrive comes pre-configured from the factory, so you don't have to
worry about reading a long manual or learning about setting up file
serving software. Of course, if you do want to enable password protection
for your files or use a special network configuration, the NetDrive's
simple web-based configuration interface will let you.

What protocols does it serve files under?
The NetDrive uses the standard SMB protocol to share its files. This makes
it compatible with Windows PCs, Macs running OS X, and Linux boxes.

2

Hi Seam

## On 2003-09-21 17:58 -0400 Sean Donelan typed:

I received a few comments about file servers not serving files by default.

There are a bunch of home SAN products on the market. They are designed
to make it very easy for customers to set up and use a home storage area
network.

  IMHO you got the terminology wrong - these are nice NAS(Network
Attached Storage) devices - not SAN

SAN(as in Fiber channel or possibly iSCSI over GigE) is a touch expensive
for SOHO(typically starting off in the 5 digit (US$) range)

3

Funny, in the earlier thread you argue against blocking ports as a means
of taking the steam out of these virii/worms. In this one, you make the
point of SMB being insecure on the Internet. Sorry if I'm replying to
thread A through thread B, but I feel they're connected.

At one point I agreed with you about blocking ports being a bad thing
and not what customers want. They want unfiltered, and full. Anything
less is theft. Right? Well, I started wavering as I learned more about
security, specifically, how insecure some protocols are by default.

What caused me to completely cross over into the "port filtering is OK"
camp was the fact that Microsoft themselves, in a "securing Windows NT"
document we found a while back, recommended that due to inherent
insecurities, NetBIOS be disabled on Internet machines. If the vendor
says it shouldn't be connected to the Internet, I tend to agree.

Obviously I won't recommend that transit providers do the same thing.
But as an access and hosting provider, I block NetBIOS by default, and
let my customers know. If a customer comes to me and says, "hey, I'm
running Exchange and my customers need to connect to it with Outlook," I
explain the risks involved, let them know they will have to be vigilant
about patching, and open the ACL for their Exchange server. If I'm
feeling particularly talkative, I explain the benefits of using a VPN
over opening 135 and its unsafe brother and sister ports.

I have yet to lose a customer due to these policies, probably because I
chose to enforce it softly and flexibly. In fact, I have converted one
customer, or rather the customer converted himself after not patching
his server quickly enough and becoming infected with Blaster. Once he
realized how vulnerable he was, he changed the methodology he used to
connect his Exchange users to his server.

Your home storage example serves to illustrate further. In today's
plug-and-play culture, end users and even lazy administrators often
overlook the security implications of some of the things they do. By
filtering and explaining to my customers what and why I am filtering, I
am helping to educate and protect them. This might be beyond the job
description of the edge ISP, but my customers seem to be happy with it.

-bob

4

What caused me to completely cross over into the "port filtering is OK"
camp was the fact that Microsoft themselves, in a "securing Windows NT"
document we found a while back, recommended that due to inherent
insecurities, NetBIOS be disabled on Internet machines. If the vendor
says it shouldn't be connected to the Internet, I tend to agree.

So basically what you are saying is that it should be the network operators
responsibility to secure every application that might be used over said
network?

Geo.

5

If it prevents network-debiliatating attacks like Blaster and friends,
YES.

-bob

6

If it prevents network-debiliatating attacks like Blaster and friends,
YES.

Ok I understand where you are coming from but that's a completely different
requirement than your previous post suggested, protecting the network is the
job of a network admin, protecting the applications using the network is
something else entirely.

As an example the recent nachia worm that causes network problems for some
devices because of the arp request issue, can be solved by patching or
replacing those devices that are susceptible to excessive arp request DOS.
This in no way requires blocking any of the protocols, it's simply a
vulnerability in certain devices that needs patched. Those devices are
susceptible to attack, not from a worm or a protocol, but from a function of
the network, and blocking the port a worm uses does nothing to protect those
devices from attack via this vulnerability. It would be trivial to write an
exploit that exposes this vuln and which blocking 135 provides no protection
at all.

Geo.