- Test - lists.nanog.org

What application runs on port 8094?
by Joe Shen 19 Aug '05

19 Aug '05

Hi, Using netflow based monitor tool, I noticed there is a lot of traffic on 8094/UDP and 4662/TCP( both exceed 1Gbps, and exist all the time) What application use that port? Is there any P2P application use UDP as transportation protocol? thanks in advance. Joe __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 1GB free storage! http://sg.whatsnew.mail.yahoo.com

4 3

Blocking certain terrorism/porn sites and DNS
by Abhishek Verma 19 Aug '05

19 Aug '05

Hi, I have a doubt which i am sure a lot of people in this list would be able to help me with. There was news that terror groups like Al Qaida, etc. are using internet to promote their terror links and these web sites provide online training on how one could assemble bombs, etc. The community as a whole wants to close all such web sites. I dont think there is any ambiguity there. My question is why cant we ban websites like, say, alqaida.com (hypothetical name), etc. from the whois database. As far as i understand if there is a website with the name of www.abc.com then it needs to register itself with the whois database (from network solutions) so that all the queries to this website can be forwarded to the corresponding nameserver. Now, if we want to block abc.com permanently then cant we simply remove this URL entry from the whois database? Will this work? Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India

19 26

Whois Query Changes in the .ORG Registry, 20 August 2005 (2-day Notice)]
by Rick Wesson 18 Aug '05

18 Aug '05

FYI -rick -------- Original Message -------- Subject: [Org-Registrars] Whois Query Changes in the .ORG Registry, 20 August 2005 (2-day Notice) Date: Thu, 18 Aug 2005 13:47:36 -0400 From: PIR Technical Support <techsupport(a)pir.org> To: org-registrars(a)publicinterestregistry.net Dear Registrars, Please be advised that on 20 August 2005 between 15:00 and 17:00 UTC, the .ORG Whois (including port 43 and www.pir.org) is scheduled for downtime and will be unavailable. Please note that the .ORG Registry System will continue to operate normally and the Shared Registration System (SRS) and the Web-based Admin Interface will remain available. Registering and manipulating domain names and other registry objects will be possible. Domains will continue to resolve normally. During this downtime, PIR will implement the following changes to the Whois function for the .ORG Registry System. 1. Whois access for public Port 43 will be restricted to 4 queries per minute per unique IP address. 2. Registrars will be provided with additional access to Whois via a dedicated Whois server, whois2.publicinterestregistry.net. These changes are being made in response to the requests we have received from registrars and registrants to minimize the potential for data mining the .ORG Registry's Whois records. Whois Access for Public Port 43 ******************************* To reduce abusive use of the public Whois and ensure access for legitimate users, PIR is executing changes necessary to restrict Whois access to the public Port 43 to a maximum of 4 queries per minute per IP address. When a user exceeds the lookup quota allocated, the system will respond with an appropriate message. Registrar Specific Whois Access ******************************** All .ORG registrars will be provided with a dedicated Whois access server, whois2.publicinterestregistry.net. Registrars will still be able to access the public Port 43 Whois server, though the 4 queries per minute limitation will exist if this access mechanism is used. It is recommended that registrars utilize the separate dedicated Whois server that will be explicitly for registrar use. This access will allow registrars to have a less restrictive access of 50 queries per minute per source IP to Whois information. This dedicated Whois server will be available from a different hostname/IP address than the public Whois service. Additional information regarding registrar access to the dedicated Whois server and IP/Subnet requirements are located at https://www.pir.org/registrars/registrar_relations/faqs/whois_limitation. Registrars may choose to utilize both the public Whois on Port 43 and the separate dedicated server concurrently. Should you have any questions, please contact PIR Technical Support. Sincerely, PIR Technical Support <techsupport(a)pir.org> +1.416.646.3308

1 0

Re: New N.Y. Law Targets Hidden Net LD Tolls
by Richard A Steenbergen 18 Aug '05

18 Aug '05

On Thu, Aug 18, 2005 at 12:19:25AM -0700, William C. Devine II wrote: > Just about all of the ISP's in my area, even those I've worked for, had > a 'disclaimer' on their user agreement that said that some of the local > phone numbers might be long distance and that the user should call the > operator to verify it is a local call before placing the call. > Is that warning enough, or are they saying the ISP must keep a database > of users' addresses and specifically warn that user that out of the 10 > local call-in numbers, based on their zip code, these three (A, B, C) > could be long distance? To quote the original pasted article: > Consumers, however, must act on the warning that Internet providers must > soon post by contacting their phone companies to find out whether a > number is truly local. > > Many service providers already post such warnings. America Online Inc. > agreed to do so in 1989, while the New York Attorney General's Office in > 2001 secured similar agreements with 25 New York-based Internet > providers including AT&T Worldnet. Sounds like the standard notice that all reputable ISPs are probably already giving. Given the very real potential for grandma and grandpa to pick a number off a list which looks like it is in their area code and end up with a multi-thousand dollar phone bill the next month, I'm surprised consumer protection folks haven't asked for such a requirement sooner. On Thu, Aug 18, 2005 at 03:07:57AM -0400, Eric A. Hall wrote: > > Seems to me the appropriate response is for the AG office to pursue the > people who are running the toll scams, not to push enforcement out to > uninvolved third parties. Having dealt with AGs in the past, I know that's > just whistling dixie, but still the notion of introducing liability is > kind of spooky. I'm not sure which part of "this seems to have nothing to do with toll scams" wasn't clear the first time around, but this response still seems to have no basis given the facts... -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

7 13

Re: Blocking certain terrorism/porn sites and DNS
by J. Oquendo 18 Aug '05

18 Aug '05

On Thu, 18 Aug 2005, William Allen Simpson wrote: > Apparently, you did.... Of course, repeated posting here will vastly > improve your opportunity to examine binaries handily delivered directly > to your own email box. ;-) "handily delivered directly to your own email box." I take note of "your own email box." So again I ask, how do you propose dealing with mail that was "handily delivered" to your clients' email boxes. Or would you just be assuming "if test -f LOOKS_LIKE_MY_EMAIL then filter_that". Either way you want to cut your comment it would take a bit of snooping to parse out traffic not destined to your own email box(es). So what do you tell your customer "Oh by the way we had to snoop in on your sessions to stop some new and improved MS uberworm." If so, when do you do it, when your network is crawling, after the fact... What if you're off by one and accidentally filter out say a contract worth a lot. Again, if I'm missing something by all means e-smack me. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x97B43D89 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89 To conquer the enemy without resorting to war is the most desirable. The highest form of generalship is to conquer the enemy by strategy." - Sun Tzu

1 0

Re: Blocking certain terrorism/porn sites and DNS
by J. Oquendo 18 Aug '05

18 Aug '05

On Thu, 18 Aug 2005, William Allen Simpson wrote: > Bad assumption. After all, terrorist is poorly defined, and from the > perspective of a particular government. Interesting you say this, same comes to mind concerning terrorists using so called cryptography simply because an agent of some government found "crypt.dll" on a machine and decided "By the love of INSERT_YOUR_DEITY_HERE they're using crypto now!" > Funny thing though, they don't seem to call their sites "spam-king", > but instead "opt-in-real-big", or the equivalent. So, we have to > examine their binaries to find the sites. Isn't this sort of ironic. To "not" want to "police" yet want to examine "binaries to find sites." And how may I ask are you going to examine these binaries via traffic. Isn't that to the tune of an illegal tap being you would unlawfully check email in and out of your network. Or did I miss something. As for filtering sites from Spam/Porn/etc., on the ISP level, someone would have to be a complete reject to do so. I know I wouldn't want anything filtered. On a corporate level, I right now have to filter a lot of unwanted junk and recently had to tone down my filtering. HR woman searched for sexual harrassment and could not get information because my rules were stringent. Filtering on an ISP/NSP level I think is a horrible idea because I believe everyone has the right to free speech and thought. Filtering is also likely to introduce unwanted latency. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x97B43D89 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89 To conquer the enemy without resorting to war is the most desirable. The highest form of generalship is to conquer the enemy by strategy." - Sun Tzu

2 1

Re: zotob - blocking tcp/445
by Roger Marquis 18 Aug '05

18 Aug '05

Andy Johnson wrote: > I think the point of many on this list is, they are a transit > provider, not a security provider. They should not need to filter > your traffic, that should be up to the end user/edge network to > decide for themselves. How is this different from a transit provider allowing their network to be used for spam? Seems the same hands-off argument was made wrt spam a decade ago but has since proved unsustainable. Our particular problem is with an ISP in Wisconsin, NETNET-WAN. We get tens of thousands of scans to netbios ports every day from their /19. This is several orders of magnitude more netbios than we see from the rest of the net combined. It's eating nontrivial bandwidth and cpu that we pay real money for. They've had our logs for months but seem incapable of doing anything about their infected customers. The suits recommend documenting time and bandwidth costs and sending a bill with a cease and desist request. My question is not what can we do about bots, we already filter these worst case networks, but what can we do to make it worthwhile for bot-providers like NETNET to police their own networks without involving lawyers? -- Roger Marquis Roble Systems Consulting http://www.roble.com/

5 4

Re: New N.Y. Law Targets Hidden Net LD Tolls
by Robert Bonomi 18 Aug '05

18 Aug '05

> From owner-nanog(a)merit.edu Thu Aug 18 01:47:56 2005 > Date: Thu, 18 Aug 2005 02:44:59 -0400 > From: "Eric A. Hall" <ehall(a)ehsco.com> > Cc: nanog(a)merit.edu > Subject: Re: New N.Y. Law Targets Hidden Net LD Tolls > > > > On 8/17/2005 10:04 PM, Fergie (Paul Ferguson) wrote: > > > A new law that's apparently the first in the nation threatens to > > penalize Internet service providers that fail to warn users that some > > dial-up numbers can ring up enormous long-distance phone bills even > > though they appear local. > > aka, make ISPs liable for other people's fraud. What's the thinking here, > anybody know? *NOT* "other people's fraud". Just when you have 'intra-LATA' toll charges for some numbers within a single area-code. If the user is on one side of the area-code, and the provider's POP is on the far side of it, you can have a what appears to be a 'local' number, that does incur non-trivial per-minute charges. Without knowing _where_ a particular prefix is, you can't tell whether there will be toll charges for that call, or not, from any given call origin. Of course, this is true for *every* call in such an area -- if the new law is actually singling out ISPs (and ISPs -only-), I expect it could be successfully challenged as 'discriminatory'. The excessive 'local toll charge' situation is most visible on calls to ISPs, because those calls tend to be somewhat lengthy -- and frequent -- thus, the 'unexpected' charges can reach significant dollar value before the phone customer gets their first bill. Life gets _really_ messy, when the ISP gets phone service from a CLEC, because there is "no telling" _where_ the ILEC uses as the 'rate point' for handing the calls off to that CLEC. And the CLEC bills their customers based on distance from the caller's location to that hand-off point. The ISP equipment may be across the street from the caller, but the ILEC-CLEC hand-off is on the far edge of the area-code. and the 'local toll charges' are applied. The CLEC can't tell you (and thus, neither can the ISP) which prefixes are a 'non-toll' call to their numbeers. And trying to get an authoritative answer from the ILEC about what charges are to the CLEC's prefix can be _very_ difficult.

6 6

Re: zotob - blocking tcp/445 (fwd)
by Bill Nash 18 Aug '05

18 Aug '05

Resent to address formatting misbehaviour: Source proto dstPort count 62.149.195.129 6 42 13018 203.69.204.250 6 445 12889 213.123.129.237 1 2048 12693 70.17.255.43 6 443 12685 217.132.56.139 6 4899 11056 209.181.111.12 6 135 8148 221.210.149.97 6 4899 7368 212.24.201.220 6 135 6451 172.131.83.244 6 135 6025 209.188.172.66 6 445 5055 80.177.36.162 6 445 4982 64.121.65.197 6 4899 4262 64.32.117.250 6 135 3954 213.144.99.241 6 445 3493 64.231.44.65 6 135 3157 213.123.129.237 6 139 2988 222.84.236.98 6 1023 2414 222.84.236.98 6 9898 2398 64.228.209.103 6 135 2305

1 0

Community Update
by Betty Burke 18 Aug '05

18 Aug '05

All: As per the NANOG Charter, the first Steering Committee meeting, via conference call, was held on August 11th. Randy Bush has been selected to serve as chair. The community can post messages to the SC, via steering(a)nanog.org. Steering Committee information, including meeting minutes, is available at <http://www.nanog.org/sc.html> The NANOG support staff and I, welcome the new SC members. We remain excited about the NANOG evolution process. We encourage the community to continue to dialogue with the newly formed Steering Committee, the existing Program Committee, and Mail List Administrators. There is a wonderful group of people working to improve the process, and they value your input. Sincerely, Betty NANOG Project Manager Merit Network

1 0