- Test - lists.nanog.org

[funsec] Security Fix: Updates on Atrivo/Intercage (fwd)
by Gadi Evron 08 Sep '08

08 Sep '08

---------- Forwarded message ---------- Date: Mon, 8 Sep 2008 04:17:29 GMT From: Paul Ferguson <fergdawg(a)netzero.net> To: funsec(a)linuxbox.org Subject: [funsec] Security Fix: Updates on Atrivo/Intercage -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Krebs add some late updates to his "Security Fix" article from Friday 5 September 2008: [snip] Update, Sunday, Sept. 7, 8:02 p.m.: I spoke today with Randy Epstein, president of WVFiber and co-founder of Host.net, which acquired WVFiber just six weeks ago. Epstein said after reading reports from Security Fix, Hostexploit.com, Spamhaus.org and others about cyber crime activities at Atrivo, WVFiber has decided to drop Atrivo as a customer. WVFiber plans to stop providing upstream connectivity to Atrivo by Wednesday or Thursday at the latest, Epstein said. That would leave Atrivo with just a single upstream provider -- Bandcon. Update, Sunday, Sept. 7, 9:15 p.m.: nLayer Communications, a company that owns a significant slice of the Internet addresses used by Atrivo/Intercage, is demanding that Atrivo vacate the space and return the addresses by Sept 30. "Atrivo/Intercage has not been a direct customer of nLayer Communications since December 2007, but they still have some legacy reallocations from our IP space," wrote nLayer co-founder Richard A. Steenbergen, in an e-mail to Security Fix. "Since they are no longer a customer, we require that they return our non-portable IP space, and have given them a deadline of September 30th to do so. If the IP space is not returned by that point, we will follow standard procedure to reclaim it, including null routing the space, and sending cease and desist letters to any network who still transits it without our permission." According to Steenbergen, Atrivo/Intercage must return roughly 7,400 IP addresses. [snip] Ref: http://voices.washingtonpost.com/securityfix/2008/09/scam-heavy_us_isp_grow s_more_i.html FYI, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIxKdMq1pz9mNUZTMRAnLcAKCRgGjZrgwr5xCmFFXPV/a0xUAlVwCaAkPL nHo38nvc5azHws2QPhshAvY= =zWoJ -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.

1 0

RE: 10GE CWDM
by Robert Boyle 08 Sep '08

08 Sep '08

At 12:03 AM 8/31/2008, you wrote: >Currently it is my understanding the 10 Gbps signals are carried on >4 x 2.5 Gbps signals that are compatible with existing CWDM and DWDM >equipment. There are 40 Gbps DWDM systems and 10 Gbps lasers on 100 >Gbps and greater capacity systems. I agree with Alex's comments that >to have 10 Gbps on a CWDM system is to have a CWDM system of at >least 40 to 100 Gbps and that is very expensive today. The only affordable CWDM 10G system I have seen although I haven't used it yet is a single 10G band at 1310 or 1550 with 8 additional 2.5G bands around it. I haven't seen any 4 band 10G CWDM boxes with XFPs for less than $5000 yet, but I would expect them in the next year or two - I'm hoping anyway. I'm out of the country at the moment and access is a bit too slow to look it up easily now. If you need the manufacturer, let me know and I'll look it up when I return. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin

5 5

RE: Force10 Gear
by hobbit＠avian.org 07 Sep '08

07 Sep '08

This once again quickly reduces to a question of real-life need in my mind. What proportion of useful traffic actually carries IP options these days? Who uses them other than fooling around with the occasional source-routing or RR exercise, if their local infrastructure even permits it to be sent? Many sites just firewall off all that stuff because in real life they never use it or need it. For them it's more trouble than it would be worth trying to process correctly, especially in a security context, so that's their accepted real-life practice. Clearly, those who design the routing iron are well aware of such practice because they optimized the hardware to process the far more typical no-options day to day traffic. While they still accomodate options it's evidently done as kind of an add-on bandaid way outside of the normal path. Now you have to ask yourself where the people making the iron cheaped out -- should they have designed in the ability to handle all these corner cases at their normal wire speed, or should they have dismissed such foolishness and concentrated on what they knew the industry actually requires? How much additional cost does anyone think ASICs to deal with options and other seldom- seen conditions at the same transit rates would incur? I think the most common answer would be "f'geddaboudit". The TTL=1 is an interesting one, but really, under normal conditions shouldn't happen that often. People tracerouting certainly shouldn't expect 100% reliability on getting the "expired" ICMP back, and automatically throttling the rate of errors from routing loops might have certain benefits so why try to handle *every* expired TTL that comes along? It seems like taking anything out of the fast-path should only be done if the slow path is good and ready to accept it, and if someone's trying to hammer the box with stupid stuff then most of it should simply be dropped. Handling it should be near the bottom of the main processor's priority list ... and rather than allow the fast iron to pile way too much crap in its inbox to be dealt with, process-switching should have a VERY short queue and be able to tell the lower levels "not now" and simply increment some obscure counter for "stupid packets dropped" without letting that impinge on the more important tasks at hand. Having the whole box fall over is the *least* acceptable result. _H*

1 0

Re: ingress SMTP
by matthew＠sorbs.net 07 Sep '08

07 Sep '08

----- Original Message ----- From: Michael Thomas <mike(a)mtcc.com> Date: Monday, September 8, 2008 7:31 am Subject: Re: ingress SMTP > > Would that it were so easy :) You also have the more daunting task > of hooking up your auth/aaa infrastructure with your MTA's, and all > of the care and feeding that entails. As a matter of interest, it took but a couple of person hours to sort this out at my last place of work, the largest time chunk in equation was the compiling of TLS and the various SASL modules into Postfix. The second from largest chunk of time was to get the script to get the information required from the various other back end mail servers on campus, including, but not limited to, Lotus Notes, M$ Exchange, and Sun/iPlanet messaging server and it's LDAP server. The only down side to the system was password changed took up to 15 minutes to get to the mail systems as there was no direct connection between the external gateways and the internal auth systems. Of course the above doesn't take into account the several weeks of political badgering and grandstanding that we endured to get the faculties to actually accept that that was the way it was going to be. They couldn't stand that there would only be incoming and outgoing mail via the central gateway. Such is life at Universities. Regards, M

2 1

Re: Force10 Gear
by David Newman 07 Sep '08

07 Sep '08

Paul Wall wrote: > Once upon a time, vendors released products which relied on CPU-based > "flow" setup. Certain vintages of Cisco, Extreme, Foundry, > Riverstone, etc come to mind. These could forward at "line rate" > under normal conditions. Sufficient randomization on the sources > and/or destinations (DDoS, Windows worm, portscans, ...) and they'd > die a spectacular death. Nowadays, this is less of a concern, as the > higher-end boxes can program a full routing table (and then some) > worth of prefixes in CAM. > > Either way, I think it's a good test metric. I'd be interested in > hearing of why you think that's not the case. Back on topic, doing a > couple of gigs of traffic at line rate is a walk in the park for any > modern product billed as a "layer 3 switch". The differentiator > between, say, a Dell and a Cisco, is in the software and profoundly > not the forwarding performance. Without disagreeing with your main point, there are still plenty of ways to bring even very large boxes to near-zero forwarding rates: 1. Set IP options. A pair of Cat 6509Es using VSS can forward packets without options at up to 770 mpps, but when packets have options the maximum is more like 20 kpps. And that's a "high-speed" example; the options forwarding rate is more like 0 pps with some other devices. Silicon that forwards packets very fast is only good when header lengths are fixed. 2. Use weak hashing algorithms. Some switches (names removed to protect the guilty) hash on the low-order three bits of MAC address to decide which of eight ASICs will forward a packet. I have heard of, but have not tested, devices that use only three bits for making OSPF ECMP decisions. Not surprisingly either technique can lead to lots of hash collisions in routed environments. 3. Offer IP multicast. Maximum forwarding rates for multicast are rather different than IP unicast with some vendors' implementations, and may be affected by group count, mroute count and amount of replication. dn

4 4

Re: only WV FIBER now peering with Atrivo / Intercage
by Brandon Butterworth 07 Sep '08

07 Sep '08

> > Anton's post that GX is still providing them transit is a bit curious, since > > I was under the impression GX had severed all ties with Atrivo. But the > > table does not lie, a path of "174 3549 27595" is clearly transit. GX, care > > to comment? > > After poking for a bit, it's unclear what, if anything, GX is or isn't > doing here. Does it matter? The implication of this thread is the imposition of an internet death penalty on this AS. In which case people will have to hound each AS they're seen behind, whatever they're providing, and that will change as they run for cover. This seems a change of tactic from just null routing people you don't like on your own network brandon

4 3

only WV FIBER now peering with Atrivo / Intercage
by Gadi Evron 07 Sep '08

07 Sep '08

http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0#AS27595 Gadi.

6 8

BGP Clueful from Windstream/Alltel? (Resend-addendum)
by Scott Morris 07 Sep '08

07 Sep '08

Is there anyone hanging around here who happens to either be or can get me in touch with a BGP-clueful person at Windstream/Alltel (AS7029)??? Unicast would be great, I hate to tie up the list with this, but the standard prescribed methods haven't worked in 72 hours now... Sorry for the resend, but if you could contact me at ccie.4713(a)gmail.com that will be much easier! Any emails to the subscribed address here won't work, which is the problem I'm attempting to solve with Windstream! :) Thanks in advance! Scott Morris swm(a)emanon.com

1 0

SMTP rate-limits [Was: Re: ingress SMTP]
by Paul Ferguson 07 Sep '08

07 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Simon Waters <simonw(a)zynet.net> wrote: >If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits. Otherwise if they send all email from their users, all they've done is take the spam, and mix it in with the legitimate email, making spam filtering harder. > Okay, I can understand why an ISP might want to apply SMTP rate-limits, but to clarify, I'm assuming you meant that ISPs (if they do block tcp/25 outbound to anything other than their own MTAs) need to watch for excessive SMTP utilization, which might indicate a spammer-client (?). ...as opposed to arbitrary SMTP rate-limits. Yes? - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIwO90q1pz9mNUZTMRAneaAJwMgmIz99bPUYJ2HgUD6Zs1MOFXgQCgmsPY eUtV2bBKymWfxNwNOgWfp5w= =bdk+ -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

4 3

BGP Clueful from Windstream/Alltel?
by Scott Morris 06 Sep '08

06 Sep '08

Is there anyone hanging around here who happens to either be or can get me in touch with a BGP-clueful person at Windstream/Alltel (AS7029)??? Unicast would be great, I hate to tie up the list with this, but the standard prescribed methods haven't worked in 72 hours now... Thanks in advance! Scott Morris swm(a)emanon.com

1 0