- NANOG - lists.nanog.org

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

Slow and Fast IP addresses on http ?
by drueegg＠emea.att.com 16 Jun '03

16 Jun '03

Did anybody ever hear about IP-addresses which get a slow treatment from some http servers ? We have a 195.212.127/24 out of a /16 PA range which is behaving very odd with multiple WEB servers but works fine with most others. When we configure an IP out of 195.212.127/24 on an direct Internet connected workstation, it takes about 1-2 minutes to start loading pages from some WEB servers, but it is fast for all other pages. When we then configure any other address out of this /24 onto the same client, everything works fine. We checked the WEB servers in question and they use various operating systems and Server software, so it does not seem to be a bug on the server side. A bug on the client side can be excluded as well because we tried various clients and it always works fine when an address outside the 195.212.127/24 is used. Routing also can't be the problem because after the "long" break traffic flows smooth. ************************************************************ 195.212.127/24 has for ex. problems with web-sites: http://www.infobel.com http://www.cevi.ch http://www.dropnet.ch No problems with web-sites: http://www.yahoo.com and http://www.google.com http://www.studerus.ch No problems to all of the above pages when using any other client IP address but the same Client Workstation and connectivity. ************************************************************ Sniffering on the client side shows, that the session establish goes through: 1. Client->Server HTTP: GET / HTTP/1.1$ 2. Server->Client TCP: TCP: src = 80, dst = 1944, ack = 0X3A577E76 ACK 3. Client->Server HTTP: HTTP/1.1 200 OK (http data is received now) Using a client address outside the range in question or going to a "good" HTTP-Server, goes through above three steps within some milliseconds. Using an address out of 195.212.127/24 and going to a "bad" HTTP-Server, works fine but then stucks for .5 to 2mins before going to above Step 3 and then all traffic flows smooth. To me it seems like the Servers are doing some intensive investigations on this IP addresses before getting the OK to process them. I have never heard of such a service. DNS/and reverse DNS can be ruled out as well as other, working addresses, are configured the same. Does anybody have any idea what the problem could be ? Thanks Dani

3 2

Re: 157.156.0.0/16 gone from ARIN
by Christopher L. Morrow 16 Jun '03

16 Jun '03

On Mon, 16 Jun 2003, Bill Robbins wrote: > Chris/Nanogians, > > Block hijacking appears pretty popular nowadays. yes :( > > One member of our local exchange had a request to advertise this unused > block: 160.122.224.0/20. It appears it was also a UBE related hijack > attempt, which failed ofcourse. > This was a block who's contact info has been marked as invalid... :( so this is likely hijacked and ARIN should be or has been working on it... > With so many defunct networks over the last 5 years, do the TLAs attempt > to recoup blocks, based on length of time out of the global routing table? > I do not believe that this is the case, but I'm not working for ARIN and don't know for sure :( > Any other systems in the works/place to expire invalid blocks quicker? > Ask ARIN ? I really don't know. :( > > Regards, > Bill R. > > On Mon, 16 Jun 2003, Christopher L. Morrow wrote: > > > > > Ok, before someone else gets saddled with this problem... ARIN pulled the > > 157.156.0.0/16 from their database. Spam-afficienados would recognize this > > as 'VMX Networks'. ARIN has decided it seems that 157.156.0.0/16 is not > > actually registered to the modern day VMX, so, if they come visit your > > sales staff for a connection using this ip block (or 134.33.0.0/16 which > > is also invalid currently) you might want to carefully consider accepting > > the routes :) > > > > --- BACK TO OPERATIONAL CONTENT! --- > > > > > > > > --Chris > > (chris(a)uu.net) > > ####################################################### > > ## UUNET Technologies, Inc. ## > > ## Manager ## > > ## Customer Router Security Engineering Team ## > > ## (W)703-886-3823 (C)703-338-7319 ## > > ####################################################### > > >

1 0

Fiber Cut: New Jersey (plus or minus a state)
by Sean Donelan 16 Jun '03

16 Jun '03

There is a report of a fiber cut in New Jersey affecting some Global Crossing service near Newark and other mid-Jersey cities. WATS/800 service through some other providers was also impacted. Depending on circuit routing, it may also affect some services in nearby states. A splicing crew has reached the fiber cut location, and making repairs.

1 0

157.156.0.0/16 gone from ARIN
by Christopher L. Morrow 16 Jun '03

16 Jun '03

Ok, before someone else gets saddled with this problem... ARIN pulled the 157.156.0.0/16 from their database. Spam-afficienados would recognize this as 'VMX Networks'. ARIN has decided it seems that 157.156.0.0/16 is not actually registered to the modern day VMX, so, if they come visit your sales staff for a connection using this ip block (or 134.33.0.0/16 which is also invalid currently) you might want to carefully consider accepting the routes :) --- BACK TO OPERATIONAL CONTENT! --- --Chris (chris(a)uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################

1 0

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

16 Jun '03

> therefore > > 3) why would anyone ever run outlook i love outlook2003. no joke, i use it every day. whenever i get an attachment that seems reasonable and i need to open it, i put it in the folder that outlook can see, and i read it. i also share a calendar (in three directions) using outlook's "iCalendar" support. i edit my cell phone's directory using a shared outlook address book. for what it's intended to do, outlook works really great. it's only when you let it open *all* the e-mail you get, that its weaknesses prevail. moral of story: i think the security model is terrible, and i think the fact that credible or similarly-dominant alternatives do not exist is reprehensible, but the applications themselves, like outlook, seem to work pretty well once you put them inside a lockbox. (i guess hundreds of companies are now in the business of selling such lockboxes, too.) the real failure, the thing that actually burns my hash, is when my spam complaints or noc correspondance are robotically bounced because they contain dangerous mime attachments of type "message/rfc822" (spam examples) or "text/plain" (traceroute or tcpdump output). if your noc or abusedesk has such a robot protecting it, you ought to be ashamed.

2 1

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

16 Jun '03

> Should ISPs control what applications their customers can run? frankly and truly, i would be satisfied if isp's wouldn't run outlook/exchange in their noc/abuse departments, so that they could safely accept mime-mail rather than bouncing it as their only means of keeping themselves virus-free. i love it when mime shows up here. mh-e just has no idea what to do with a "pif" or "exe" file. the whole concept of having to run "mime defang" at the gateway because an abuse desk worker or backbone engineer has a fragile user agent is completely ridiculous and there is no possible explaination for it. (if this is your situation then quit, or fire somebody, as appropriate.)

4 3

Re: Rescheduled: P2P file sharing national security and personal security risks
by neil＠DOMINO.ORG 16 Jun '03

16 Jun '03

> The problem - to try to steer this bus back onto topic - is the sheer amount > of self-policing that the powers-that-want-to-be want us to do. Or it > becomes our fault. Who should do the policing then Peter?

3 3

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

16 Jun '03

> the thing that actually burns my hash, is when my spam > complaints or noc correspondance are robotically bounced because they > contain dangerous mime attachments of type "message/rfc822" (spam > examples) or "text/plain" (traceroute or tcpdump output). if your noc > or abusedesk has such a robot protecting it, you ought to be ashamed. Or they may be happy thinking their NOC is more 0day virus proof rather than hoping a 3rd party will update their scanner in time Who'd want to risk the NOC falling to the same problem that's just taken out the network they're trying to fix? brandon

3 2