August 2003 - Test - lists.nanog.org

RE: Port blocking last resort in fight against virus
by Temkin, David 13 Aug '03

13 Aug '03

True, but at that time you didn't have illegitimate traffic on port 80, either. Future engineering could be worked around this issue. -----Original Message----- From: Matthew Kaufman [mailto:matthew@eeph.com] Sent: Wednesday, August 13, 2003 12:09 PM To: 'McBurnett, Jim'; nanog(a)merit.edu Subject: RE: Port blocking last resort in fight against virus > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of McBurnett, Jim >... I really can not image > legitimate traffic on 135.. My problem with this approach is that, in 1985, you could have said "I really cannot imagine legitimate traffic on port 80". (On the other hand, you could probably say that today and be mostly right) Matthew Kaufman matthew(a)eeph.com

1 0

RE: Port blocking last resort in fight against virus
by McBurnett, Jim 13 Aug '03

13 Aug '03

Jack, et al. As a larger than average end user and what could be called a small ISP, I really can not image legitimate traffic on 135.. who in there right mind would pass NB traffic in the wild? I dunno, may it is just that Old military security mindset creeping into my brain housing group. Can someone enlighten me? What is legitimate 136 traffic? J -----Original Message----- From: Jack Bates [mailto:jbates@brightok.net] Sent: Tuesday, August 12, 2003 12:31 PM To: Mans Nilsson Cc: nanog(a)merit.edu Subject: Re: Port blocking last resort in fight against virus Mans Nilsson wrote: > > Your chosen path is a down-turning spiral of kludgey dependencies, > where a host is secure only on some nets, and some nets can't cope > with the load of all administrative filters (some routers tend to > take port-specific filters into slow-path). That way lies madness. > Secure? Who's talking about secure? I'm talking about trash. Not blocking the port with a large group of infected users means that your network sends trash to other people's networks. Those networks may or may not have capacity to mean your network's trash. Temporarily blocking 135 is not about security. A single infection within a local net will infect all vulnerable systems within that local net. A block upstream will not save local networks from cross infecting. However, it does stop your network from sending the trash out to other networks which may have smaller capacities than your network does. Of course, perhaps a good neighbor doesn't really care about other people's networks? Perhaps there is no such thing as a good neighbor. It's kill or be killed, and if those other networks can't take my user's scanning them, then tough! There is legitimate traffic on 135. All users I've talked to have been understanding in a short term block of that port. They used alternative methods. I have a lot of valid traffic still cranking out the other Microsoft ports. -Jack

5 4

Chicago routers and Genuity estates
by Hank Nussbacher 13 Aug '03

13 Aug '03

I really hate to do this but I have no choice. IUCC terminated its services at the Genuity colo site at 216 W. Jackson, Chicago in May 2002. We had a financial disagreement about the final bill and Genuity refused to let us remove our routers from the site until our bill was paid. We finally agreed on final payment and we sent that in April 2003. The check has been cashed, but no one now replies to any of our letters (http://www.genuityestate.com/) So until we have a letter allowing us to remove our 7500 routers from their colo site, they are held hostage. Has anyone else been stuck in this situation and what have you done to get a letter of release from Genuity Estates? Thanks, Hank

1 0

The impending DDoS storm
by Jason Frisvold 13 Aug '03

13 Aug '03

All, What is everyone doing, if anything, to prevent the apparent upcoming DDoS attack against Microsoft? From what I've been reading, and what I've been told, August 16th is the apparent start date... We're looking for some solution to prevent wasting our network resources transporting this traffic, but at the same time trying to allow legitimate through... So, is anyone planning on doing anything? Thanks, -- --------------------------- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering friz(a)corp.ptd.net RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --------------------------- "Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955]

3 2

RE: The impending DDoS storm
by Jason Frisvold 13 Aug '03

13 Aug '03

On Wed, 2003-08-13 at 10:14, Ingevaldson, Dan (ISS Atlanta) wrote: > It might be somewhat tricky to block TCP/80 going to windowsupdate.com. I agree... but then, who needs updates anyways.. *grin* > Regards, > =============================== > Daniel Ingevaldson > Engineering Manager, X-Force R&D > dsi(a)iss.net > 404-236-3160 > > Internet Security Systems, Inc. > The Power to Protect > http://www.iss.net > =============================== > > > -----Original Message----- > From: Stephen J. Wilcox [mailto:steve@telecomplete.co.uk] > Sent: Wednesday, August 13, 2003 10:38 AM > To: Jason Frisvold > Cc: nanog(a)merit.edu > Subject: Re: The impending DDoS storm > > > > > On Wed, 13 Aug 2003, Jason Frisvold wrote: > > > All, > > > > What is everyone doing, if anything, to prevent the apparent > upcoming > > DDoS attack against Microsoft? From what I've been reading, and what > > I've been told, August 16th is the apparent start date... > > > > We're looking for some solution to prevent wasting our network > > resources transporting this traffic, but at the same time trying to > > allow legitimate through... > > > > So, is anyone planning on doing anything? > > See previous discussion on filtering... > > > Other than that experience says if these things turn out to be big > enough to > cause an issue then they quickly burn themselves out anyway > > Steve -- --------------------------- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering friz(a)corp.ptd.net RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --------------------------- "Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955]

1 0

RE: Port blocking last resort in fight against virus
by McBurnett, Jim 13 Aug '03

13 Aug '03

>So give up trying to control the actions of the end nodes by >destroying the edge. Make sure that complaints reach the correct >responsible person. Limit your involvement to careful excerpts from >your customer/IP-address database, or better yet, register them in >the RIR registry so that others having complaints can reach them >without wasting your time. Intersting concept... MY upstream disagrees.. They, who shall remain nameless at this point, are doing a horrible job at policing their other customers, refuse to SWIP the block to me claiming they are working on it (been a year now), and they feel they need to know about whatever complaints they get about me. HMM, if they have gotten complaints, then I haven't gotten any!! And I have complained about other customers and never seen a fix.. One system was code red infected and had no FW, after a few weeks, I tracked them down and called them myself, and got told that <ISP> never called them!!! (I reported it 5 times) This is a great idea, but I very much doubt that most ISP's will even do it. And if ISP's did this.. NOTE the spammers, they would always lie about WHOIS, RWHOIS, contact info... I dunno, there is no perfect solution here... Except, as a community we need to enforce RIR policies and actual enforce our own AUP's. (NO shots being fired here, but as we all know some ISPs AUPs are like a law-- only effect the good citizen and not the high $ customer) just my 2c worth.. J

3 2

Re: RPC errors
by Steven M. Bellovin 12 Aug '03

12 Aug '03

In message <Pine.LNX.4.33.0308121243210.814-100000(a)morannon.the-infinite.org>, "Dominic J. Eidson" writes: > >On Mon, 11 Aug 2003, Jack Bates wrote: > >> Sean Donelan wrote: >> >> > http://isc.sans.org/diary.html?date=2003-08-11 >> > The worm uses the RPC DCOM vulnerability to propagate. One it finds a >> > vulnerable system, it will spawn a shell and use it to download the actual >> > worm via tftp. >> > >> > The name of the binary is msblast.exe. It is packed with UPX and will self >> > extract. The size of the binary is about 11kByte unpacked, and 6kBytes >> > packed: > >Has anyone seen/heard of this virus propagating through email in any way? > >We appear to have been infected on a network that is very heavily >firewalled from the outside, and are trying to track down possibly entry >methods the worm might have had... A large number of networks have unknown and unauthorized back doors. If it's a decent-sized network and you haven't audited it, don't assume that the firewalling is effective. (My co-author on "Firewalls and Internet Security" book, Bill Cheswick, is CTO of a startup that maps intranets for just this reason.) --Steve Bellovin, http://www.research.att.com/~smb

3 2

RE: RPC errors
by Vachon, Scott 12 Aug '03

12 Aug '03

addendum: These are broadband cable users. All PCs. -----Original Message----- Sent: Tuesday, August 12, 2003 1:57 PM To: NANOG Subject: RE: RPC errors >Has anyone seen/heard of this virus propagating through email in any way? >We appear to have been infected on a network that is very heavily >firewalled from the outside, and are trying to track down possibly entry >methods the worm might have had... I know of a few associates who have been infected (on home networks) but according to them (I have yet to verify) not via e-mail. These folks are running Windows XP Pro with Norton AV & Personal firewall. Microsoft update is running as well. Systems continuously reboot by RPC with a one minute countdown, even when disconnected from the network. Again, I have yet to get hands-on to the systems to do more research. Hope that bit helps. ~S~ Disclaimer: My own two cents. Learn more about Paymentech's payment processing services at www.paymentech.com THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information intended only for the use of the recipient(s) named above. If you are not the intended recipient, you may not print, distribute, or copy this message or any attachments. If you have received this communication in error, please notify the sender by return e-mail and delete this message and any attachments from your computer.

1 0

RPC errors
by Jack Bates 12 Aug '03

12 Aug '03

I'm showing signs of an RPC sweep across one of my networks that's killing some XP machines (only XP confirmed). How wide spread is this at this time. Also, does anyone know if this is just generating a DOS symptom or if I should be looking for backdoors in these client systems? -Jack

7 8

RE: RPC errors
by Vachon, Scott 12 Aug '03

12 Aug '03

>Has anyone seen/heard of this virus propagating through email in any way? >We appear to have been infected on a network that is very heavily >firewalled from the outside, and are trying to track down possibly entry >methods the worm might have had... I know of a few associates who have been infected (on home networks) but according to them (I have yet to verify) not via e-mail. These folks are running Windows XP Pro with Norton AV & Personal firewall. Microsoft update is running as well. Systems continuously reboot by RPC with a one minute countdown, even when disconnected from the network. Again, I have yet to get hands-on to the systems to do more research. Hope that bit helps. ~S~ Disclaimer: My own two cents. Learn more about Paymentech's payment processing services at www.paymentech.com THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information intended only for the use of the recipient(s) named above. If you are not the intended recipient, you may not print, distribute, or copy this message or any attachments. If you have received this communication in error, please notify the sender by return e-mail and delete this message and any attachments from your computer.

1 0