All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] SMB traffic routing/blocking...
Date: Thu, 05 May 2011 15:47:14 +0000	[thread overview]
Message-ID: <4DC2C682.2090601@riverviewtech.net> (raw)
In-Reply-To: <4DC1C569.3040705@bowenvale.co.nz>

On 05/04/11 17:11, Don Gould wrote:
> Sorry, my bad.

No problem.  We are all human.

> I want to block, drop, what ever, Microsoft networking... wins? but I do
> want to permit internet networking (for what of some better terms.

Ok.

So we are only talking about filtering TCP / UDP ports 137, 138, 139 and 
445.  (Isn't M$ networking fun...)

> I don't want users on the 2.0 network to see the 'shares' on the 3.0
> networks in 'network neighbourhood'.

I think I know what you are after.

> I know this could be achieved by simply putting everyone in different
> work groups rather than the default of 'workgroup' (or 'home' depending
> on what version of windows you're using). But I don't control the
> computers, so I can't do that.

Now we are getting in to some M$ networking issues.

I think the proper term (as I (mis)understand it) that you are after is 
"browse".

Just because the computers are in a different workgroup does not mean 
that they won't be able to see each other.  In fact, workgroups mean 
little any more.  If any thing, the "workgroup" is sort of (very rough 
analogy) like your local subnet in that it takes marginally more effort 
to go out side of it, but still very possible to do.  -  In short, using 
different workgroups would not suffice for what you are wanting.

> If user 2.35 sets up WAMP on their PC, I do want 3.45 to be able to see
> that. http://192.168.2.35/ ... blar :)

*nod*  TCP / UDP ports 137, 138, 139 and 445

> What I want is... When a user browses the "network" (windows term), I
> want them to see DonsNAS\192.168.x.0_Share That's where I eventually
> want to end up.

Heh.  Now more M$ networking fun.

I think you are about to run in to the network visibility vs 
accessibility issue.

Specifically, if you want computers to be able to "browse" the network 
(neighborhood) and find computers to access, you are going to have to 
have a functional browse master list.  Complicating this is the fact 
that you have multiple networks (subnets) trying to tie together.

In the end I think you are going to end up with a single unified browse 
maser list that all the computers are on.  Now, that does not mean that 
the computers will be accessible, just that they are on a list.

> Everyone on the x.0/24 network gets access to 1.xGb of shared space
> where they can put stuff they want to share with everyone else on their
> network. People on y.0/24 will have their share on the same NAS (which
> is actually a nice Debian box running samaba). The share is to be fully
> open to everyone in x.0 but not visible to people in y.0 etc.

Ok.

So you are exploiting some of Samba's features as a central file server.

> Think in terms of a block of apartments where each apartment is getting
> a x.0/24. I'm wanting to give all the users in apartment 1 a network and
> some shared space so they can transfer files etc but I don't want the
> people in apartment 2 seeing the files of apartment 1. However I don't
> have control of the computers, so I can't do stuff like ACLs etc.

Heh.

Isn't multi-tenancy networking fun?

> I don't want them to be able to 'browse the network', errr... I don't
> want them to be able to "browse" the other networks.

Here "browse" can mean multiple things: 1) see the computers on a list 
that are connected to the network and 2) access a given computer and see 
the contents there on.

I think you are going to have to live with #1 and use IPTables to 
control #2 via firewalling.

> Ya, that's not what I want. I only want to drop the smb traffic. Is that
> port 137? or do I need to drop more than that?

To be save, I drop both TCP and UDP for ports 137, 138, 139 and 445.

(We actually only need to block a subset of those ports, but I don't 
bother to remember exactly what is needed and just block those 8 ports 
and have been fine for the past decade.)

> If I do what you just said then skype between networks will break won't
> it? or it will travel out the public IP and transit to another peer?

As I broadly said it, yes.  However, if we refine it to be for the 8 
ports in question, no.

Question:  Do you want to control the 2., 3. and 4. network's access to 
the the 1. network so that they can only get to the servers IP, or can 
they access the entire 1. network?

At this point, I think your firewall rules will be such that you first 
allow SMB/CIFS traffic (from any network) to the 1. network -and- from 
the 1. network (to any network). and then you drop / reject any other 
SMB/CIFS traffic.  (You may want to refine "1. network" to be "the NAS 
server's IP".)

> Thanks for the help man :)

You are welcome.



Grant. . . .


P.S.  For the record, you really are crossing two completely different 
network layers.  One is the TCP/IP & routing layer and the other is the 
M$ Windows Networking layer.  Doing this can be interesting (and I don't 
mean in a good way), somewhat difficult, and sometimes prone to 
compromise (as in I don't like it but it works, not the security breach) 
and failure.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

      parent reply	other threads:[~2011-05-05 15:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-04 21:30 [LARTC] SMB traffic routing/blocking Don Gould
2011-05-04 21:45 ` Grant Taylor
2011-05-04 22:11 ` Don Gould
2011-05-05 15:47 ` Grant Taylor [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DC2C682.2090601@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.