- Test - lists.nanog.org

Re: Fun new policy at AOL
by Johnny Eriksson 28 Aug '03

28 Aug '03

Matthew Crocker <matthew(a)crocker.com> wrote: > Technically no, There is no reason for a customer to have direct > access to the net so long as the ISP can provide appropriate proxies > for the services required. Good idea. I'll start working on the SSH proxy tomorrow. > -Matt --Johnny

1 0

RE: Fun new policy at AOL
by Michel Py 28 Aug '03

28 Aug '03

> Matthew Crocker wrote: > Shouldn't customers that purchase IP services from an ISP > use the ISPs mail server as a smart host for outbound mail? Trouble is with some ISPs you get more rejections when using their mail servers than when havong your own, not to mention theirs eating some email from no reason, having limits in attachment size, you can't have a mailing list that way, etc. Michel.

6 5

XO as a provider
by Bil Herd 28 Aug '03

28 Aug '03

Anyone have positive or negative experiences with XO as a 'tier1' provider? We are re-evaluating our backbone connections and looking for new where appropriate. Bil Herd - INS

2 1

Re: Fun new policy at AOL
by Simon Waters 28 Aug '03

28 Aug '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Demon announcement was interesting to me as a subscriber. Historically Demon allocated static IP addresses to (nearly) all dial up users. For many businesses this was a cheap and effective way to have their own email servers running. For those of us running businesses (from home) in areas without ADSL, it is still convenient, although suddenly looks a lot less good value for money. I understand AOL have asked Demon for a list of all legitimate sources of SMTP traffic. Seems AOL intend to maintain a whitelist of senders, where as historically I was led to believe they maintained their own blacklist. The policy is flawed, as maintaining a straight list of legitimate senders is a huge task. They have already failed at maintaining accurate blacklists, and accurate lists of dynamic IP address ranges, so I don't see why this one will work better. I can't believe the effort wouldn't be better spent on some easier task (like replacing SMTP! or agreeing reverse DNS entries to indicate legitimate mail senders (or entries to flag dynamic IP addresses - probably easier to implement) which stops virus and spam email (sent without the DNS maintainers knowledge) - obviously should be called an XM record). I understand the issues with dynamic IP addresses, but where an IP address is readily traceable, blacklisting, not whitelisting seems the obvious answer. End users do have a various legitimate reasons for wanting to send SMTP mail from their own static IP addresses. Not least for Demon it has been more reliable, their own servers often being overworked through mailing lists, viruses and spam. Also the SMTP relays often ended up in various blacklists because they were relaying spam from one of the many thousands of subscribers. Being forced to use the ISP SMTP relay merely means more multistage relays, and big ISP SMTP servers relay spam much more efficiently than their subscribers boxes on the end of narrow pipes, and worse you can't blacklist the big ISPs SMTP relays without losing bucket loads of genuine mail. In a similar fashion as someone who does work with DNS I run my own DNS caching server (sometimes even caching off the ICANN root servers ;-). I'd be somewhat upset if my ISP insisted I send all DNS queries via their caches. The various country code maintainers would probably get less reports, so I guess that is a plus for someone ;-) Not every end user is some naive computer user who needs lots of hand holding. -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/TjywGFXfHI9FVgYRApWxAKCuVNkifrrKkHhUm5Fvgxoge3OXfwCdFSoS Hrl4YkfjXYRrMeHDD0zke60= =r5d+ -----END PGP SIGNATURE-----

1 0

W32/Sobig-F - Halflife correlation ???
by Matt Martini 28 Aug '03

28 Aug '03

I've scanned my Netflow logs for activity associated with the 20 machines that SoBig was targeting and I found some very curious activity. I routed traffic to these 20 ips to Null0. At 3:09 I started getting traffic from 10 of the 20 machines to a Halflife server on my network. This continued until 6:14pm. The conversations could not be productive because of my Null route, but what were these machines trying to do? Even more interesting is the fact that these machines were supposed to be shutdown before 3:00. How could they be sending data to this halflife server? I suspect that the addresses are spoofed, but to what end? Are there any halflife vunerabilies that the virus writers are using? It just seems like too much of a coincidence that 10 out of 20 machines were hitting this server. I have the original Netflow data and the complete logs. Below is a sample of what I was seeing. Port 27015 is the normal Halflife port. Anyone have any ideas? or seeing anything similar? Read: Date,Time,SrcIP,SrcPort,DstIP,DstPort,Protocol,Packets,Bytes 2003/08/22 15:09:54 67.73.21.6.50416 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:10:00 12.232.104.221.64550 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:10:03 61.38.187.59.43445 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:10:07 67.9.241.67.17414 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:10:09 63.250.82.87.2956 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:10:12 24.197.143.132.18637 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:10:23 61.38.187.59.64072 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:10:31 67.73.21.6.27900 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:10:39 65.177.240.194.1448 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:10:46 63.250.82.87.33876 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:11:16 65.177.240.194.40713 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:11:18 61.38.187.59.58060 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:11:25 24.197.143.132.4336 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 15:11:40 67.9.241.67.6812 -> XXX.XXX.XXX.XXX.27015 17 1 37 [...] 2003/08/22 18:13:27 65.95.193.138.11565 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 18:13:31 12.232.104.221.32662 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 18:13:35 61.38.187.59.28106 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 18:13:37 24.33.66.38.19736 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 18:13:38 67.9.241.67.51452 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 18:13:46 65.95.193.138.46930 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 18:13:53 61.38.187.59.16641 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 18:13:59 63.250.82.87.56358 -> XXX.XXX.XXX.XXX.27015 17 1 37 2003/08/22 18:14:09 12.232.104.221.19923 -> XXX.XXX.XXX.XXX.27015 17 1 37 Total = 1751 flows from 15:09:54 to 18:14:09 Servers hitting the Halflife machine ------------------------------------ 12.232.104.221 24.33.66.38 24.197.143.132 24.202.91.43 61.38.187.59 63.250.82.87 65.95.193.138 65.177.240.194 67.9.241.67 67.73.21.6 __________________________ http://www.invision.net/ _______________________ Matthew E. Martini, PE InVision.com, Inc. (631) 543-1000 x104 Chief Technology Officer matt(a)invision.net (631) 864-8896 Fax _______________________________________________________________________pgp_

6 9

Cross-country shipping of large network/computer gear?
by Matthew Zito 28 Aug '03

28 Aug '03

Hello, I was wondering if anyone could provide any advice or suggestions on shipping heavy/bulky equipment (~300 pounds, about a half-rack worth of gear) on short notice cross-country? We're obviously looking to minimize cost, but realistically it can't be in transit for more than two days. Are there any companies or methods people would recommend? Thanks in advance for the help. Thanks again, Matt -- Matthew Zito GridApp Systems Email: mzito(a)gridapp.com Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.com

17 24

RE: Fun new policy at AOL
by McBurnett, Jim 28 Aug '03

28 Aug '03

-On Thursday, August 28, 2003 4:18 PM, Matthew Crocker <matthew(a)crocker.com> -wrote: -> -> Shouldn't customers that purchase IP services from an ISP use the ISPs -> mail server as a smart host for outbound mail? - -At least here in DE there are resellers of DTAG which offer DSL connections -without any SMTP relay. If you want relaying you also have to order a domain -via them. More funny: you cannot deliver mails to DTAG (actually T-Online) -as the resellers use address space of DTAG and hence the DTAG servers -believe you are a customer of them and should use the internal relays ... - -Arnold I wouldn't say that the answer is to use a relay.. I have had the problem, and due to the business we are in, we sometimes are forced to email proofs that can be as big at 10 Meg, zipped.... Don't think many would allow us to realy that...... J

1 0

Re: GLBX ICMP rate limiting (was RE: Tier-1 without their own backbone?)
by Robert Boyle 28 Aug '03

28 Aug '03

At 09:26 AM 8/28/2003, you wrote: >It takes some education to the customers, but after they understand why, >most are receptive. > >Especially when they get DOS'ed. We have been rate limiting ICMP for a long time, however, it is only recently that the percentage limit has been reached and people have started to see "packet loss" as a result. However, the fact that customers stay up and are not affected by the latest DOS attacks and real traffic makes it to the proper destination makes a slight increase in support calls well worth it. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey

1 0

Re: Fun new policy at AOL
by Jonathan Hunter 28 Aug '03

28 Aug '03

> Sometime mid last week, one of my clients--a state chapter of > a national > association--became unable to send to all of their AOL > members. Assuming > it was simply that AOLs servers were inundated with infected emails, I > gave it some time. The errors were simply "delay" and "not > delivered in > time specified" errors. AOL appear to have recently changed their MX receiving policies, see the following demon.announce post: http://groups.google.com/groups?selm=xVIP4XA5f7M%24EwzW%40demon.net&oe=UTF-8 &output=gplain --- cut here --- One such scheme uses a list of "end user" IP addresses on the basis that such users will only be sending legitimate email via their own ISP's "smarthost" email server. The idea is that the blocklist will be able to block non-legitimate email because it arrives directly. In particular it should block "spam" sent via insecure systems or virus/worm infections. We have recently been in discussion with AOL who are, at a future date, planning to implement just such a scheme as they have found, working with many ISPs around the world, that it significantly impacts their incoming spam volumes. --- cut here --- Regards, Jonathan

1 0

Re: Max TNT ping thing
by Matthew Crocker 28 Aug '03

28 Aug '03

On Wednesday, August 27, 2003, at 11:10 PM, Edward Murphy wrote: > Is anyone having this problem on a unit with the mad-2 cards? > > We are not experiencing the reboots/lock ups on our APX 8000. We are using the Ethernet card with the dongle. E-100-V I think. We are using the Channelized DS-3 card We are using 96 port madd2 modem cards (5 modem cards, 480 modems) Our APX is not even close to 25% capacity. admin> show Controller { left-controller } ( PRIMARY ): Reqd Oper Slot Type { right-controller } UP UP ( SECONDARY ) { shelf-1 slot-34 0 } UP UP madd2-card { shelf-1 slot-35 0 } UP UP madd2-card { shelf-1 slot-36 0 } UP UP madd2-card { shelf-1 slot-37 0 } UP UP madd2-card { shelf-1 slot-38 0 } UP UP madd2-card { shelf-1 slot-39 0 } UP UP t3-card { shelf-1 slot-40 0 } UP UP ether3-card admin> admin> list [in SLOT-INFO/{ shelf-1 slot-39 0 }] slot-address* = { shelf-1 slot-39 0 } serial-number = 1038406179 software-version = 10.0 software-revision = 2 software-level = "" hardware-level = " K" software-release = "" admin> read slot-info {1 40 } SLOT-INFO/{ shelf-1 slot-40 0 } read admin> list [in SLOT-INFO/{ shelf-1 slot-40 0 }] slot-address* = { shelf-1 slot-40 0 } serial-number = 10516825 software-version = 10.0 software-revision = 2 software-level = "" hardware-level = " C" software-release = "" admin> ls ls Flash card 1: /: current/ 0 Fri Sep 29 11:36:36 2000 /current: tntt3.ffs 416034 Mon Dec 16 19:47:20 2002 Version 10.0.2 tntmadd.ffs 1726366 Mon Dec 16 19:51:10 2002 Version 10.0.2 tntenet3.ffs 446882 Mon Dec 16 19:48:22 2002 Version 10.0.2 apxsr.ffs 3031819 Mon Dec 16 19:46:34 2002 Version 10.0.2

1 0