- Test - lists.nanog.org

RE: Operational impact of filtering SMB/NETBIOS traffic?
by Roeland Meyer 19 Nov '00

19 Nov '00

> From: Ethan Butterfield [mailto:primus@veris.org] > Sent: Sunday, November 19, 2000 11:45 AM > To: Jim Mercer > Cc: nanog(a)nanog.org > Subject: Re: Operational impact of filtering SMB/NETBIOS traffic? > > From: Jim Mercer <jim(a)reptiles.org> > > Subject: Re: Operational impact of filtering SMB/NETBIOS traffic? > > > > as i understand it, ipsec doesn't use ports. > > > > Yes and no. IPSec uses UDP port 500 for the ISAKMP key > exchange and the > tunnel setup, but all other traffic is IP Protocol 50 (ESP) > or 51 (AH). > Most firewalls I've seen block wierd (i.e., just about > everything that's > not standard TCP or IP Protocol 1 (ICMP)) by default, or at > least flag it > as strange. In shops that block SSH, this is also what they do and is exactly what I meant. I apologize for not communicating clearly and typing poorly (too many decades writing code). > It should not be hard to set up a persistent IPSec tunnel between UNIX > hosts in order to pass SMB/NETBIOS traffic. You could even do it > router-to-router in gateway mode and have the traffic be > cleartext on the > internal side of both networks, and 3DES/SHA-1 to the rest of > the world. When possible, I do this. The whole point of this is that transit providers should not be filtering unless specifically requested. > For the Road Warrior, though, it's going to be somewhat more difficult > without using a VPN, as the Win32 implementations of IPSec are > somewhat...lacking. (Or at least they were six months ago when I last > tried the SSH IPsec shim for NT4.) Win2K's built-in IPSec > makes life much > easier...if you've got clients using Win2K. Can't vouch for > interoperability between Win2K-UNIX, though. Never tried it myself. I did, just as soon as it came out. It sux! Active directory also does a number on the DOMAIN stuff in Samba. Fortunately, it allows backwards compatibility to old-style WinNT4SP5 hosts. In fact, and I am sure that MS did it to mess with the Samba folks, the entire DOMAIN stuff has been re-spec'd and re-written. --- I can't afford to have a preference, I must be agnostic.

1 0

RE: Operational impact of filtering SMB/NETBIOS traffic?
by Roeland Meyer 19 Nov '00

19 Nov '00

The scenario that you miss is Win2K lap-tops and workstations with Unix servers. Our policies are unix-unix = local-only NFS, and win-unix = Samba. This is mainly because of known flaws with NFS over internet security, but also because of the expense and difficulty of getting win-anything to do NFS. > -----Original Message----- > From: Jim Mercer [mailto:jim@reptiles.org] > Sent: Sunday, November 19, 2000 9:29 AM > as far as samba working better than NFS, that is a religious argument. No it isn't, NFS has known exploits. I've had a server owned three times in the past four years, twice via BIND and once via NFS. None via Samba. > if you are using SMB to share files between unix systems, > then i have a bit > of trouble with that last line of the above. see: above > personally, i can't think of any applications where i would > attempt to do > any kinda filesystem sharing across the internet. How about collaboration servers? > i suspect the widespread use of SMB on the internet is again, > because of the > brain-dead applications produced by a braindead company and software > produced by lazy programmers working in the braindead company's API's. > > why does the application need a "share"? can it not just > negotiate the > information needed without mounting the entire office over a > 33.6K connection? You ARE joking, right? I haven't seen a 33.6K connection in years. A part of every deal is LAN access that usually shares, at the least, a T1. Also, you are ignorant of the way Win PDCs operate. I DHCP connect to the local LAN and log into my home PDC, from the clients site. Otherwise, the client has to give me access to their PDC and their PDC winds up owning my lap-top and I have to re-configure this for every client (sometime three per day). Everytime my profile gets blown away. At the end of the day, my lap-top would be a useless piece of junk and I would have to re-install the OS...not! > > > geez, if the filter was there, are you saying that people who > > > _need_ SMB shares are too brain-dead to come up with a straight > > > forward way to make it get around the filter? > > > > There is no straight-forward way around a filter, by definition the > > straight-forward way is to not have the filter! > > no, the brain-dead easy way around the filter is to have no > filter at all. > > i'm not an SMB user (outside a few LAN's where we explicitly > drop it all > on the floor before it gets out of the network). You just told me that you are not in marketing/management, you don't do docs, you don't collaborate on docs, and/or you never leave your corporate site to do any of the above. > could you not use an IPSec tunnel from one LAN to another, > then run SMB > over that tunnel? > > is it not possible to use ssh port forwarding to move the > packets through > a secure tunnel that way? When I can, that's what I do, via F-Secure port forwarding. However, many shops explicitly block port 22. This kills IPsec as well.

4 3

RE: Operational impact of filtering SMB/NETBIOS traffic?
by Roeland Meyer 19 Nov '00

19 Nov '00

> From: Jim Mercer [mailto:jim@reptiles.org] > Sent: Sunday, November 19, 2000 10:38 AM > > On Sun, Nov 19, 2000 at 10:25:18AM -0800, Roeland Meyer wrote: > > > why does the application need a "share"? can it not just > > > negotiate the information needed without mounting the entire > > > office over a 33.6K connection? > > > > You ARE joking, right? I haven't seen a 33.6K connection in years. > > well, you live a sheltered life. > > i'm kinda getting tired of people who design/implement wide > area applications > while wearing blinders. So am I. Transit providers shouldn't be filtering without specific request. > > > could you not use an IPSec tunnel from one LAN to another, > > > then run SMB over that tunnel? > > > > > > is it not possible to use ssh port forwarding to move the > > > packets through a secure tunnel that way? > > > > When I can, that's what I do, via F-Secure port forwarding. > However, many > > shops explicitly block port 22. This kills IPsec as well. > > if many shops are explicitly blocking port 22, but allowing > SMB, then they > need their heads examined. We agree there. I prefer the SSH connection. That's why we went to the trouble to set it up in the first place. > i'm not sure how port 22 effects IPsec. Kills it dead, just like SSH. > it seems that you are arguing that filtering SMB will > inadvertantly effect > a bunch of boneheads that don't know what they are doing > beyond point and > click. Say that to a dot-com VP and manage to keep your business relationship (paycheck). If you can do that, I want you on my sales force. > i don't have a problem with that. sure would clear off a > bunch of bandwidth > from my networks to further enable the users who aren't boneheads (or > being managed by boneheads). The "A" students work in research labs, run by the "B" students, in companies, that are managed by the "C" students, for the owners, that were the "D" students. They may be boneheads, but who has the money?

4 3

Re: Operational impact of filtering SMB/NETBIOS traffic?
by Ethan Butterfield 19 Nov '00

19 Nov '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: Jim Mercer <jim(a)reptiles.org> > Subject: Re: Operational impact of filtering SMB/NETBIOS traffic? > > as i understand it, ipsec doesn't use ports. > Yes and no. IPSec uses UDP port 500 for the ISAKMP key exchange and the tunnel setup, but all other traffic is IP Protocol 50 (ESP) or 51 (AH). Most firewalls I've seen block wierd (i.e., just about everything that's not standard TCP or IP Protocol 1 (ICMP)) by default, or at least flag it as strange. It should not be hard to set up a persistent IPSec tunnel between UNIX hosts in order to pass SMB/NETBIOS traffic. You could even do it router-to-router in gateway mode and have the traffic be cleartext on the internal side of both networks, and 3DES/SHA-1 to the rest of the world. For the Road Warrior, though, it's going to be somewhat more difficult without using a VPN, as the Win32 implementations of IPSec are somewhat...lacking. (Or at least they were six months ago when I last tried the SSH IPsec shim for NT4.) Win2K's built-in IPSec makes life much easier...if you've got clients using Win2K. Can't vouch for interoperability between Win2K-UNIX, though. Never tried it myself. - -- "By four o'clock, I've discounted suicide in favor of killing everyone else in the entire world instead." - Spider Jerusalem, "Transmetropolitan" -----BEGIN PGP SIGNATURE----- Comment: For info see http://www.gnupg.org iD8DBQE6GC2u36NTGsm+2Z4RArBVAJwPWUyTX9fzVctkx+RkVzPtdonzUgCeNaVY s/0K1mD1Vvd/xM+/4kyHzzk= =UwTF -----END PGP SIGNATURE-----

1 0

RE: Operational impact of filtering SMB/NETBIOS traffic?
by Roeland Meyer 19 Nov '00

19 Nov '00

> From: Jim Mercer [mailto:jim@reptiles.org] > Sent: Saturday, November 18, 2000 8:49 PM > > On Sat, Nov 18, 2000 at 08:19:12PM -0800, Roeland Meyer wrote: > > 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? > > well, maybe if there was a global filter on SMB then the > brain-dead company > that produces the brain-dead software will wake up and > realize that maybe > it shouldn't produce software that by default leaves their users open > to intrusion or viruses. You are assuming (wrongly) that microshit is the only one using that protocol. Have you never heard of the samba project? I remember explicitly referencing smb.conf files. That's Unix/Samba bud. I also mentioned that it works better than NFS. I don't recall microshit-anything shipping with NFS. Believe it or not, one or two of us actually know what we're doing. > geez, if the filter was there, are you saying that people who > _need_ SMB > shares are too brain-dead to come up with a straight forward > way to make > it get around the filter? There is no straight-forward way around a filter, by definition the straight-forward way is to not have the filter!

2 1

RE: Operational impact of filtering SMB/NETBIOS traffic?
by Roeland Meyer 19 Nov '00

19 Nov '00

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. 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? 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. > -----Original Message----- > From: Scott Call [mailto:scall@devolution.com] > Sent: Tuesday, November 14, 2000 12:21 PM > To: nanog(a)nanog.org > Subject: Operational impact of filtering SMB/NETBIOS traffic? > > > > > Due to an increasing number of intrusions into windows-based machines > through unprotected shares, I've started filtering both incoming and > outgoing traffic for our customers on ports 138/139. > > So far this has caught a fair amount of traffic coming from > customers, > but none have called to complain about a lack of connectivity. > > Because this traffic is IP traffic, I wanted to ask others on > this list > how they treat SMB traffic on their backbones? > > Thanks > -Scott > >

7 6

Re: [eggnog] Re: NANOG isn't NANOG anymore
by jamie rishaw 19 Nov '00

19 Nov '00

by the way.. in the immortal words of rbush.. "how do i configure my router for this?" jamie

1 0

NANOG isn't NANOG anymore
by Craig Klingler 19 Nov '00

19 Nov '00

I'm working with a Japanese Company and for the first time realize what it means to say the Internet is Global. This company has a Tier 1 domestic backbone in Japan (covering the country of Japan and connecting to the Japanese major peering points). They also have partial ownership in undersea cables (fiber)that extend from Japan to the United States and Japan to the UK. So bandwidth and networking are not the problem. I'm sure my information is dated, but at one point I thought that 80% of all Internet traffic gets switched in the United States. Now, having studied the traffic patterns for our Japanese company and how much of the traffic stays in country, I would say I need to see some more data. But, I think I can safely say the United States handles the "lions share" of the global IP traffic, and will continue to do so until distributing hosting and caching make an impact. However, The NA in NANOG shouldn't apply any more. Political issues aside, at least ICANN saw fit to established three governing bodies for naming, ARIN, RIPE/NCC and APNIC. I write this more of an appeal, as this Japanese company wants to establish peering (not transit) in the US, and although by name, I recognize many of the "good old boys" in the Internet Tier 1 Backbone discussions, I am not one of them. I have read this list for some time now, but this is my first post. I have seen conversations ranging from graduate school discussions to school yard scuffles, so I am ready for my share of daggers. My question is, how does the Internet get opened up to new International companies, such as the one I am working for? I know this has been tried before via Savvis and a recent group that I know Exodus is part of. I also recognize there is as much brilliance in NANOG as there is sarcasm. If this was a business issue, the suits would have made their zillions and moved on, which is why I'm writing NANOG. Thank You, Craig Klingler klingler(a)onramp.net

1 0

NetRail Issue at MAE-West
by Joe Budion 19 Nov '00

19 Nov '00

NetRail's NOC currently has ticket 636 open for an outage at MAE-West. At least one NSP (SprintLink) continues to route traffic into the black hole of NetRail at MAE-West (the two also peer at AADS and other spots.) An equipment swap is needed to repair the equipment in question. Time required is unknown. This has been a day-long outage thus far. They claim to still be working the issue/ticket. #5 sl-bb21-stk-5-0.sprintlink.net (144.232.9.206): TTL Exceeded, ttl=251, 61 ms #6 sl-bb22-stk-15-0.sprintlink.net (144.232.4.242): TTL Exceeded, ttl=250, 60 ms #7 sl-w1-mae-1-0-0.sprintlink.net (144.232.8.1): TTL Exceeded, ttl=249, 60 ms #8 No response (): , ttl=, ms #9 at-1-1-1--3.pr1.Dallas2.Tx.us.netrail.net (205.215.61.106): TTL Exceeded, ttl=245, 992 ms #10 No response (): , ttl=, ms #11 at-0-2-0--0.tr1.Austin2.TX.us.netrail.net (205.215.63.157): TTL Exceeded, ttl=243, 681 ms #12 Zyan-100M.tse1.Austin2.Tx.us.netrail.net (209.44.90.74): TTL Exceeded, ttl=243, 180 ms ...lovely routing loop... TraceRoute - Saturday, November 18, 2000 14:36:52 #6 sl-bb21-stk-5-0.sprintlink.net (144.232.9.206): TTL Exceeded, ttl=251, 60 ms #7 sl-bb20-kc-11-0.sprintlink.net (144.232.9.205): TTL Exceeded, ttl=252, 60 ms #8 sl-bb20-kc-8-0.sprintlink.net (144.232.2.118): TTL Exceeded, ttl=252, 60 ms #9 sl-bb21-kc-8-0.sprintlink.net (144.232.2.117): TTL Exceeded, ttl=252, 60 ms ...and back to "normal"... #6 sl-bb20-chi-10-2.sprintlink.net (144.232.9.118): TTL Exceeded, ttl=251, 40 ms #7 sl-nap1-chi-0-0-0.sprintlink.net (144.232.26.237): TTL Exceeded, ttl=250, 30 ms #8 ameritech.netrail.net (206.220.243.58): TTL Exceeded, ttl=248, 40 ms #9 at-1-1-1--2.pr1.Dallas2.TX.us.netrail.net (205.215.61.113): TTL Exceeded, ttl=245, 91 ms #10 ge-0-0-0--0.tr1.Dallas2.Tx.us.netrail.net (205.215.61.149): TTL Exceeded, ttl=244, 100 ms #11 at-0-2-0--0.tr1.Austin2.TX.us.netrail.net (205.215.63.157): TTL Exceeded, ttl=243, 110 ms ...very flaky... It takes a different route every minute ;-) Unfortunately only one of the three passes traffic at an acceptable rate... Best regards, joe =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joe Budion Client Services Representative DSL Provisioning www.CISP.cc - Changing Internet Speed & Performance -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

general PA and PGH uunet outages
by deeann mikula 18 Nov '00

18 Nov '00

i just got off the phone with uunet. kudos to them for the new feature of updating their telephone message with master ticket number for widespread damage. i learned from their message that is a fiber cut affecting PA, NJ and NY, even before i spoke to a tech. however, i was calling cause only one of our t1s dropped out. turns out i was one of the first callers (where's my prize?!) about another generalized problem, this one affecting some switches in the PGH area. master ticket for the PGH area is #308557 master ticket for the PA area is #cns308532 (this tt# transcribed quickly from message!) deeann m.m. mikula network administrator telerama internet -- http://www.telerama.com abuse@telerama.com/spam@telerama.com 1.877.688.3200x501

1 0