- Test - lists.nanog.org

UDP port 137 Question
by C. Jon Larsen 07 Jan '98

07 Jan '98

Is there any *valid* reason to see UDP traffic directed at a unix box's port 137 coming from IP sources across the internet ? The unix servers in question are most definitely *not* running samba, and there is absolutely no NT anywhere on this customer's network (that is seeing the incoming UDP traffic directed at an IP destination address on port 137). (A couple of 95 boxes scattered across an Ethernet comprise the Micro$oft part of the network). None of the 95 boxen are running any file or print serving (sharing) resources. I can't think of any valid reason to see this traffic, personally. Anybody out there that can present a scenario where I would expect to see these UDP packets coming back in ? netbios-ns 137/tcp nbns netbios-ns 137/udp nbns netbios-dgm 138/tcp nbdgm netbios-dgm 138/udp nbdgm netbios-ssn 139/tcp nbssn =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- C. Jon Larsen Email: jlarsen(a)ford.ajtech.com Systems Engineer Voice: +1.804.353.2800 x118 A&J Technologies http://www.ajtech.com PGP Key fingerprint: 8A 62 4C 6E 1E 3C CD 63 B3 16 1A 1B D2 61 EE 97 PGP Public key available at: http://ford.ajtech.com/CJL.txt =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

12 15

Re: UDP port 137 Question
by Paul Thornton 07 Jan '98

07 Jan '98

I noticed similar port 137 hits a while back, and after a bit of investigating discovered that every time a colleague visited a web site (using Netscape, incidentally) the server sent a port 137 request back to the client PC. Initially I thought this was a "helpful" MS extension in their server, but have since seen port 137 hits from their nameservers as well. This probably points to some interesting name lookups going on at there end, which results in a NetBIOS name lookup being sent back. Somewhere I have the address of the server in question - I'll dig it out if there is interest. If nothing else, their hit count will go up ;-) Paul -- Paul Thornton, Network Engineer, London Internet Exchange Ltd. Tel: 07000 783797 Mobile: +44 467 372205

2 1

Re: route ingress
by Vadim Antonov 07 Jan '98

07 Jan '98

The issue here is people deliberately injecting bogus routing information. Any "chain of trust" systems break down if there's somebody abusing the trust. This means that tier-1 ISPs shouldn't trust routing information coming from tier-2 ISPs, etc. That leaves the only workable option - cryptographical authentication of routes, by the presense of signature by a trusted address space registry. --vadim Date: Wed, 7 Jan 1998 12:39:26 +0300 (MSK) From: "Alex P. Rudnev" <alex(a)Relcom.EU.net> To: Vadim Antonov <avg(a)pluris.com> I am sorry, but what for do you want it? Why is not efficient to use AS identification in conjuction to IP prefix filtering at the 1't level ISPs (and may be 2'nd level too), based on the NIC data base. On Tue, 6 Jan 1998, Vadim Antonov wrote: > Date: Tue, 06 Jan 1998 13:23:47 -0800 > From: Vadim Antonov <avg(a)pluris.com> > To: "Sean M. Doran" <smd(a)clock.org>, nanog(a)merit.edu > Subject: Re: route ingress > > Sean M. Doran wrote: > > > Vadim Antonov ?avg(a)pluris.com? writes: > > > > ? The only real solution is strong cryptographical authentication of > > ? the ownership of routing prefixes. For some reason i do not see > > ? any serious work in that direction being done. > > > > This would be much easier if we had a bottom-up > > hierarchical addressing structure rather than the > > current top-down one. > > I quite agree with that (though i'm not convinced that "bottom->top" > allocation combined with recursive NATting is the best architecture). > > However, this does not preclude doing authentication with the current > routing system. > > --vadim

1 0

Re: route ingress
by Sean M. Doran 07 Jan '98

07 Jan '98

Vadim Antonov <avg(a)pluris.com> writes: > The only real solution is strong cryptographical authentication of > the ownership of routing prefixes. For some reason i do not see > any serious work in that direction being done. This would be much easier if we had a bottom-up hierarchical addressing structure rather than the current top-down one. Consider the distribution of cryptographically authenticated connectivity maps a la NIMROD or a multi-level LS protocol, for example, for path authentication vs. how one would distribute and authenticate reachability information with the current addressing structure. Sean.

4 3

MCI Contact
by Forrest W. Christian 07 Jan '98

07 Jan '98

Could someone from MCI Internet please drop me a personal e-mail? I need to get some contact information. I'll explain more off-list. No, I don't need the NOC number, as this is not something the NOC needs to deal with. Thanks. P.S. Sorry to everyone else on the list. Wish I would have appropriated a couple of business cards from someone from MCI last NANOG I attended. - Forrest W. Christian (forrestc(a)imach.com) ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------

1 0

cisco FAQ UPDATE
by Dave Van Allen 07 Jan '98

07 Jan '98

Happy New Year! We have completed the move of the old CISCO-FAQ to its new home and final resting spot. ftp.fast.net/cisco This is the new semi-official site and directory of both the old (deferred) FAQ and soon the new revamped FAQ. There are a few announcement files in the directory that will go into detail on how we are working to get an up to date FAQ, at least started by end of January. Before the holidays, I asked if anyone would be kind enough to send me <dave(a)fast.net> config files (stripped of passwds and incriminating stuff) along with a brief explanation of the more advanced sections. I received a few - THANK YOU! However I need many more - Specifically I am interested in collecting complex BPG configs that exploit the more advanced attributes such as communities, MED's and route reflectors. We also need ATM and FDDI config examples, a touch of CLNS, a sprinkle of IS-IS and OSPF with just a splash of IPX. SMNP, ACL's and general IP interface examples will also go along way. I will keep all configs sent confidential, and will only use sections in the FAQ that are generic. I will run everything past the donator prior to public consumption, and of course you'll get a plug for the help. We need general questions and answers too. We have set up a LISTSERV for the sole and exclusive purpose of submitting info to the FAQ. Details are in the .ann file on the ftp site. A special cry goes out to the gurus, you know who you are. You run the Net or at least help keep it running. I'd really like to hear from you - with even a quick config snippet, anything. We have a small team set up and ready to finally get an updated FAQ out after many years. We're committed and we appreciate your help! Best regards, David Van Allen - FASTNET(tm) / You Tools Corporation dave(a)fast.net (888)321-FAST(3278) http://www.fast.net FASTNET - Business and Personal Internet Solutions

1 0

Re: UDP port 137 Question
by Joe Pruett 07 Jan '98

07 Jan '98

this is a wonderful feature of ms internet explorer. when it connects to an http server, it also tries to make an smb connection as well.

2 1

Re: UDP port 137 Question
by Joe Provo - Network Architect 06 Jan '98

06 Jan '98

>One would hope the backbones aren't passing 255.255.255.255 around to come >in via his Internet connection You would be surprised at the *source* addresses on packets that hit some of my borders: [typical 1918 addresses clipped] deny ip 127.0.0.0 0.255.255.255 any (56 matches) deny ip host 0.0.0.0 any (1818 matches) I find source 0/0 to be truly entertaining. Cheers, Joe -- Joe Provo, Network Architect 508.229.8400 x3006 Network Operations Center Fax 508.229.2375 UltraNet Communications, Inc. <jprovo(a)ultra.net>

1 0

Re: Deciding whose network block is whose?
by Sean M. Doran 06 Jan '98

06 Jan '98

Geoff Huston <gih(a)telstra.net> writes: > I am looking to the regional registeries to take some level of initiative > and provide clients of their address allocation service the ability to > sign the allocation and then the client can sign the routing request to the > provider which the provider can verify against the regional registry. > We went through this in discussion in the room at the time and it > looked like a viable and useful approach. Yes, but this is only part of the problem. I mean, fantastic idea, but then it's not exactly transitive. How do I know I can trust that Telstra's announcements have been authorized by the people responsible for the prefixes in question? Worse, since I do not talk directly with Telstra, how do I know I can trust the intermediary networks not to have performed (or fallen victim to) AS path surgery? Moreover, other than prefix-length filtering, what can I do to prevent falling victim to subnet-announcement attacks? Note that a larger CIDR block can still fall victim to announcements of /19s in networks which use The Satanic Filters. Perhaps you have some idea other than mine (prayer) for scalably solving these and similar issues? Sean.

2 1

Re: UDP port 137 Question
by gary flynn 06 Jan '98

06 Jan '98

> From: "C. Jon Larsen" <jlarsen(a)ford.ajtech.com> > > Is there any *valid* reason to see UDP traffic directed at a unix box's > port 137 coming from IP sources across the internet ? The unix servers in > question are most definitely *not* running samba, and there is absolutely > no NT anywhere on this customer's network (that is seeing the incoming UDP > traffic directed at an IP destination address on port 137). (A couple > of 95 boxes scattered across an Ethernet comprise the Micro$oft part of > the network). None of the 95 boxen are running any file or print serving > (sharing) resources. > > I can't think of any valid reason to see this traffic, personally. Anybody > out there that can present a scenario where I would expect to see these > UDP packets coming back in ? > > netbios-ns 137/tcp nbns > netbios-ns 137/udp nbns > netbios-dgm 138/tcp nbdgm > netbios-dgm 138/udp nbdgm > netbios-ssn 139/tcp nbssn Windows boxes will attempt name resolution using whatever protocols are configured...TCP/IP, Netbios, Netbios/TCP, Netbios/IPX, etc. Our name servers and some other public boxes are hit all the time because of this. (A campus WINS server would really cut down on this but we haven't got around to it yet.) I've seen a *LOT* of LAND attacks using these ports too. (i.e. 134.126.1.2 port 137 -> 134.126.1.2 port 137) Is the source address and port the same as the destination? I also seem to recall that using a Web browser (IE only?) on a Windows client with TCP and Netbios configured will hit these ports but I don't remember the details. If the Win95 boxes are browsing exterior NT based Web servers, those servers may be attempting name lookups for the Win95 boxes to the authoritative name servers. Or someone may just be scanning the network looking for someone with their C:, N:, etc. drives published to the world with no passwords :) Gary Flynn Network Analyst James Madison University

1 0