RE: Operational impact of filtering SMB/NETBIOS traffic?
How closely have you looked at Samba sources? BTW, I've done it through SSH tunnels too. The problem is that some SAs (a fair large percentage) think that a port labeled "secure" (port 22) means that they have to take special care to make sure that it is blocked (yes, they are the recently lobotomized). So, three-quarters of the time, a VPN is not do-able and you are forced to go plain-text direct. If, in addition, you block the NetBIOS ports then you block application-level access for 80% of internet users.
-----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Sunday, November 19, 2000 8:19 AM To: Roeland Meyer Cc: 'Scott Call'; nanog@nanog.org Subject: Re: Operational impact of filtering SMB/NETBIOS traffic?
On Sat, 18 Nov 2000 20:19:12 PST, Roeland Meyer <rmeyer@mhsc.com> said:
shares on the internet? We use SMB/Samba INSTEAD of NFS because we believe SMB to be more secure. smb.conf certainly gives more security options than exports does.
Don't confuse "more options" with "more security".
A protocol can have dozens of options, but yet be fundementally insecure. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
On Sun, Nov 19, 2000 at 09:06:06AM -0800, Roeland Meyer wrote:
How closely have you looked at Samba sources? BTW, I've done it through SSH tunnels too. The problem is that some SAs (a fair large percentage) think that a port labeled "secure" (port 22) means that they have to take special care to make sure that it is blocked (yes, they are the recently lobotomized). So, three-quarters of the time, a VPN is not do-able and you are forced to go plain-text direct. If, in addition, you block the NetBIOS ports then you block application-level access for 80% of internet users.
So you're hypothesizing that this customer will: 1) Be behind a firewall that blocks ssh. 2) Be behind a firewall that DOESN'T block SMB. 3) Not be in a position to have that policy changed. 4) Not be violating his corporation's policies when he connects through you.
On Sat, Nov 18, 2000 at 08:19:12PM -0800, Roeland Meyer wrote:
You'd have LOTs of complaint from me and many of my clients. Many of us log into our external gateway PDCs from foriegn locations. We have shares because we want shares.
Yikes. Isn't that what secure road-warrior VPNs are for?
You are considering killing off a whole bunch of legitimate use because some are too brain-dead to not have unintentional shares on the internet?
Intentional or not, sniffing SMB passwords and share info doesn't require much skill.
We use SMB/Samba INSTEAD of NFS because we believe SMB to be more secure.
That's like saying the electrical chair may be far more appealing to some than lethal injection. NFS and SMB are both insecure and inefficient mechanisms for file transfer over the public Internet. SMB may be the lesser of the two evils, but it's really irrelevant. Why not use ssh/sftp, or for the Unix impaired, some https-based file transfer interface, instead? On Sun, Nov 19, 2000 at 09:06:06AM -0800, Roeland Meyer wrote:
[...] in addition, you block the NetBIOS ports then you block application-level access for 80% of internet users.
Howso? Sounds like you'd be promoting responsible usage instead. -adam
You know, this all started with "Hey, what do you all think of blocking such and such port." Clients who get connections from us* expect an open pipe, no content censorship, and no impediment to action. This type of discussion "Block SMB", "Block SMTP to external servers", "Block harmful-of-the-day-thing" should be limited to those special handheld customers who pay for managed secure networks. It is clear (to me) that customers who get a connection to the net do NOT want that connection limited nor censored. Ehud *us being those who provide Internet Protocol connectivity in the Free World (tm). p.s. As NANOG goes the way of Usenet, the name of the group is less important than creating impediment to S/N reduction. Adam Rothschild wrote:
On Sat, Nov 18, 2000 at 08:19:12PM -0800, Roeland Meyer wrote:
You'd have LOTs of complaint from me and many of my clients. Many of us log into our external gateway PDCs from foriegn locations. We have shares because we want shares.
Yikes. Isn't that what secure road-warrior VPNs are for?
You are considering killing off a whole bunch of legitimate use because some are too brain-dead to not have unintentional shares on the internet?
Intentional or not, sniffing SMB passwords and share info doesn't require much skill.
We use SMB/Samba INSTEAD of NFS because we believe SMB to be more secure.
That's like saying the electrical chair may be far more appealing to some than lethal injection. NFS and SMB are both insecure and inefficient mechanisms for file transfer over the public Internet. SMB may be the lesser of the two evils, but it's really irrelevant. Why not use ssh/sftp, or for the Unix impaired, some https-based file transfer interface, instead?
On Sun, Nov 19, 2000 at 09:06:06AM -0800, Roeland Meyer wrote:
[...] in addition, you block the NetBIOS ports then you block application-level access for 80% of internet users.
Howso? Sounds like you'd be promoting responsible usage instead.
-adam
On Mon, 20 Nov 2000 09:21:10 MST, Ehud Gavron said:
It is clear (to me) that customers who get a connection to the net do NOT want that connection limited nor censored.
Unfortunately, it's NOT clear that this is the case. The average customer just THINKS they want something. The question of whether it's something actually reasonable to do is a different issue.... Remember - the *reason* this is a point worth discussing at *ALL* is because such a large percentage of customers don't have a CLUE - if (for instance) 98% of the shops had enough clue to close down open shares, we'd not be seeing so many scans for them. I suspect that if a large percentage of Tier 1/2 carriers actually filtered ports 137 through 139, we'd not be seeing anywhere near the amount of QAZ and similar activity. And as has been pointed out, you can ALWAYS punch a hole in the filter for customers who like to live risky, or they can find other ways to tunnel their packets. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
On Mon, 20 Nov 2000 09:21:10 MST, Ehud Gavron said:
It is clear (to me) that customers who get a connection to the net do NOT want that connection limited nor censored.
Unfortunately, it's NOT clear that this is the case. The average customer just THINKS they want something. The question of whether it's something actually reasonable to do is a different issue....
What doesn't make sense in that argument is why you couldn't just simply upsell the customer to a managed fw solution etc if that's the concern. Educate them, and let them decide based on the education they received.
Remember - the *reason* this is a point worth discussing at *ALL* is because such a large percentage of customers don't have a CLUE - if (for instance) 98% of the shops had enough clue to close down open shares, we'd not be seeing so many scans for them.
Well, again, I don't believe in 'censoring' traffic by default. I do believe in offering options for those people who decide to do so and can't/don't want to do it themselves.
I suspect that if a large percentage of Tier 1/2 carriers actually filtered ports 137 through 139, we'd not be seeing anywhere near the amount of QAZ and similar activity.
I wouldn't be so sure, particularly because of the legal exposure...
And as has been pointed out, you can ALWAYS punch a hole in the filter for customers who like to live risky, or they can find other ways to tunnel their packets.
At SP scale? Think again. Cheers, Chris -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
On Mon, Nov 20, 2000 at 12:03:57PM -0500, Christian Kuhtz wrote:
What doesn't make sense in that argument is why you couldn't just simply upsell the customer to a managed fw solution etc if that's the concern. Educate them, and let them decide based on the education they received.
Because it doesn't just affect them; it affects you, your customers, and your business.
I wouldn't be so sure, particularly because of the legal exposure...
Does anybody have a live example of this supposed legal exposure, to counter all the many examples those of us who don't believe in it have given?
At 11:54 11/20/2000 -0500, Valdis.Kletnieks@vt.edu wrote:
I suspect that if a large percentage of Tier 1/2 carriers actually filtered ports 137 through 139, we'd not be seeing anywhere near the amount of QAZ and similar activity. And as has been pointed out, you can ALWAYS punch a hole in the filter for customers who like to live risky, or they can find other ways to tunnel their packets.
Well, we'd actually see a good deal of QAZ still, if Tier One was filtering it... QAZ primarily hunts in the same class C it lives in. Aside from that, I certainly agree that it is not our job to dictate what our customers can or cannot do on the big-eye-nternet. What I also think is that it *is* our responsibility to maintain the sanctity of our networks. I don't see any customers up-in-arms because of the lack of directed broadcast services on most of our networks, and I think this situation is roughly analogous. The point is this: 137-139 are used for NetBIOS and Samba, neither of which are secure (or even supported by their vendors, AFAIK) for use out on the Internet. I think we can all agree that anyone using them in that situation, shouldn't be. --- Ben Browning <benb@oz.net> oz.net Network Operations Tel (206) 443-8000 Fax (206) 443-0500 http://www.oz.net/
[..]
The point is this: 137-139 are used for NetBIOS and Samba, neither of which are secure (or even supported by their vendors, AFAIK) for use out on the Internet. I think we can all agree that anyone using them in that situation, shouldn't be.
I don't at all disagree. But, this isn't the same question as.. does this equal to automatically and strictly blocking such traffic? Who am I to say a customer can't use them if they decide to do so? Etc etc. Now, that isn't the same as saying 'I must not provide a mechanism for customers to protect themselves if they want to'. The opposite is true, I would like to see such mechanisms. And I think this conversation would be a lot more fruitful if we focused on how to provide mechanisms that are opt-in/opt-out/whatever and how to deal with operational, legal, engineering impact of such a decision, and provide this in a transparent, easily managable fashion to the customer. -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
Ben Browning wrote:
The point is this: 137-139 are used for NetBIOS and Samba, neither of which are secure (or even supported by their vendors, AFAIK) for use out on the Internet. I think we can all agree that anyone using them in that situation, shouldn't be.
The problem is that 137-139 are just numbers. The fact that a typically insecure application runs over port 137/139 as opposed to say, 25609, makes no difference. If the logic follows, then block port 21, 111 and maybe even port 80. I'm sure we can find over zealous security experts making claims that those services are inherently insecure as well. Someone will come up with a way of doing file sharing over another port number, over another protocol, over a conforming application (e.g. HTTP) and probably using encryption so you can't tell what it is. I think the end-to-end principle should guide us when people approach these problems with generalized network solutions ...with extreme trepidation. I have no problem with organizations that control their own AS and want to block certain, vulnerable ports. I can even see ISPs being somewhat service oriented towards their customer who may be completely security unaware, but to foster this type of activity as a real solution I think is a mistake. It doesn't really make the Internet any more secure. It simply moves the security problem around. If people continue to follow this approach, then soon we end up doing content inspection looking for tunneled protocols, encrypted and who knows what kinds of trickery all over TCP port 80. Yuck. That'll be "The Day the Internet Died". The closer we can get security to the end hosts the better. John
John Kristoff wrote:
The problem is that 137-139 are just numbers. The fact that a typically insecure application runs over port 137/139 as opposed to say, 25609, makes no difference. If the logic follows, then block port 21, 111 and maybe even port 80. I'm sure we can find over zealous security experts making claims that those services are inherently insecure as well. Someone will come up with a way of doing file sharing over another port number, over another protocol, over a conforming application (e.g. HTTP) and probably using encryption so you can't tell what it is.
If users are smart enough to switch the port and encrypt their traffic, then obviously there's nothing to worry about. The original suggestion was to protect users that probably don't even realize they have shares open to the world.
For what it is worth we have filtered 137-139 at our border for years with no complaints. We are non-transit and primarily consumer based. We post the filtering policy. ESP and AHP are permitted (for VPN's). Mark Radabaugh VP, Amplex (419)833-3635 mark@amplex.net
participants (10)
-
Adam Rothschild -
Ben Browning -
Christian Kuhtz -
Ehud Gavron -
John Kristoff -
joshua stein -
Mark Radabaugh -
Roeland Meyer -
Shawn McMahon -
Valdis.Kletnieks＠vt.edu