June 2003 - Test - lists.nanog.org

BTinternet problems?
by Stewart, William C (Bill), RTSLS 17 Jun '03

17 Jun '03

Yes, it appears they had problems: Power failure leads to BTo blackout By Tim Richardson Posted: 17/06/2003 at 11:46 GMT http://theregister.com/content/22/31248.html

1 0

Re: Slow and Fast IP addresses on http ?
by Steven M. Bellovin 17 Jun '03

17 Jun '03

In message <20030616210129.GM751(a)reifa-wave.karrenberg.net>, Daniel Karrenberg writes: > >tcp-wrapper. > >Check DNS of the client address affected, forward and reverse. > It might also be port 113 -- some sites try to query your tcp port 113, and wait for a timeout if the port is firewalled. A better solution than blocking it is to send an immediate RST. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

4 3

Re: Slow and Fast IP addresses on http ?
by Steven M. Bellovin 17 Jun '03

17 Jun '03

In message <g3u1aovd6e.fsf(a)sa.vix.com>, Paul Vixie writes: > >smb(a)research.att.com ("Steven M. Bellovin") writes: > >> It might also be port 113 -- some sites try to query your tcp port 113, >> and wait for a timeout if the port is firewalled. A better solution >> than blocking it is to send an immediate RST. > >people who depend on tcp/113 deserve everything stupid that happens to them. >dropping SYN packets or returning a fixed string are both better than sending >an immediate RST. (false confidence being valued less than low confidence.) >i was rather shocked to discover tcp/113 clientness enabled by default in >postfix and sendmail. but even widespread ignorance does not call for >widespread coddling such as returning immediate RST's. I'm not defending the practice, I'm defending myself against the practitioners. My email, etc., was being delayed because the site I was sending to was trying to query my non-existent tcp/113 server, and I was dropping SYNs. Now, I either send an immediate RST or use Erik Fair's identd, depending on my mood. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

2 2

Fall Meeting with ARIN
by Susan Harris 17 Jun '03

17 Jun '03

Hi everyone - just a quick reminder that our fall meeting will be held in the fabulous city of Chicago, once again in conjunction with ARIN. NANOG meets Sun.-Tues., Oct. 19-21, and ARIN Wed.-Fri., Oct. 22-24. The Call for Presentations will go out in the next few weeks - see you soon.

1 0

Spammers use Trojans
by Sean Donelan 17 Jun '03

17 Jun '03

I don't know what proof MessageLabs has, but they report that spammers are breaking into home PCs of unsuspecting users to send junk mail. http://www.vnunet.com/News/1141610 Spammers are increasingly hijacking home PCs to send junk mail, according to MessageLabs. The managed email service provider claims to have proof of spammers using viruses to plant Trojan malware on PCs to provide remote access.

10 12

Spam from weird IP 118.189.136.119
by Pascal Gloor 17 Jun '03

17 Jun '03

Getting SPAM from 118.189.136.119 relayed by rr.com ? this network is not allocated, nor announced. I have been looking everywhere to find if it has been announced (historical bgp update databases, like RIS RIPE / CIDR REPORT / etc..)... I didnt found anything.... this probably mean rr.com is routing that network internaly. "Received: from [118.189.136.119] by smtp-server1.cfl.rr.com with NNFMP;" If there is any rr.com guy around. Could you please check this? Thanks, Pascal

7 8

RE: Mobile code security (was Re: rr style scanning of non-customers)
by Herb Leong 16 Jun '03

16 Jun '03

> As far as I could tell, the vector was AOL IM. So, it's not only M$ > and outlook. Why oh why are vendors shipping with defaults like no > restrictions on "buddy" downloads and execution? Hiya, The same reason why some linux installs were/are totaly open: They wanted it to work outta the box. It's viewed that it's better to have your product widely in use and insecure (so now the user has to come back and pay you or someone else for security--or take care of it themselves) than to have it secure from the get-go and not used much because it is too much of a PITA to get up and running... /herb

1 0

lightship troubles in boston
by Curtis Maurand 16 Jun '03

16 Jun '03

Anyone know what's going on in Boston with Lightship? Curtis

1 0

Re: Mobile code security (was Re: rr style scanning of non-customers)
by Brandon Butterworth 16 Jun '03

16 Jun '03

> I think pauls point may be: > If they use text based mailers I know, intrinsically safe is good but that's not what managment wants so you end up with bodges to make their choices safer. Some people may go too far > It's a lot harder to open up a microsoft executable on a *nix > machine than a windows machine. We have ongoing pressure to switch to MS based systems to tie in with corporate stuff (being a Unix island is hard) so this problem interests me, we've thought about filtering but more extracting info where possible rather than rejecting (so your text/plain would get turned into plain text). We'd reject html only along with various document formats > If your abuse desk can't take the complaint, you can't do anything > about it. The abuse/security desks are in most cases small, understaffed > and hidden to prevent them from being overworked yet do enough that > you're not called a spam/abuse harborer. Often filtered through a front desk that risk breaking it or running it. I think holding those messages somewhere someone with a clue can look at them if they need to and only passing plain text through intermediate systems & people is best. We'd like to be able to see the virus for forensics so we're not going to be allowed to get these messages anywhere near Exchange anyway. brandon

3 2

IntraLATA vs. InterLATA Ckt Reliability
by William R. Lorenz 16 Jun '03

16 Jun '03

Can someone with a bit of experience in telco line engineering speak to IntraLATA vs. InterLATA DS-1 circuit reliability? More specifically, is it more likely for multiple DS-1 circuits to be aggregated using a single piece of multiplexing equipment when heading into another LATA, thus increasing the chance of combined failure of two diverse circuits at a single point? I would love to have two diverse T1 circuits coming into the offices, but it looks like they'll ultimately traverse the same telco switches, both at the local and regional interconnection levels (? more info ?), and it seems as though this presents increased risk. We have entrance failities for just one LEC in our office building here, and I understand that a new telco buildout would require lots of investment. I've actually talked with LEC engineers about the various switching stations in the area, and it seems as though everything is aggregated through a single central office before hitting the other LATAs. Have others encountered this same kind of topology in the past? What are some of the things that can be done to help ensure circuit diversity? Lots and lots of questions, I know. ;) Any insight into standard telco engineering practices would be great and very much appreciated! Tnx. -- _ __ __ ___ _| | William R. Lorenz <wrl(a)express.org> \ V V / '_| | http://java.sun.com/; http://www.linux.org/ \./\./|_| |_| "[...] But it's turtles all the way down."

2 1