- NANOG - lists.nanog.org

RE: mitigating botnet C&Cs has become useless
by Fergie 04 Aug '06

04 Aug '06

I really didn't intend for this discussion to run down a rat-hole like this, but there it is. If you're going to pass-the-buck on this to (OS flaws) or that (stupid user tricks), then there are bigger problem than I thought. Regardless of existing flaws, user idiosyncracies, etc., we still have to mitigate _all_ emerging threats. Period. Your customers, and mine, expect nothing less. If you think that it's not worth your time, then continue to ignore it, but at least leave the rest of us to deal with the carnage without being a nayayer poo-poo'ing efforts to the contrary. - ferg -- "Bora Akyol" <bora(a)broadcom.com> wrote: I see you are an optimist. As much as I like to build more technology, in this case neither more technology, nor more manpower devoted to service providers and networking is going to fix this problem. There is a real good analogy to this going on in Santa Clara county (SF Bay Area) where West Nile virus is a real threat. Initially the county tried to spray and in general kill the mosquitos. Well, it turns out that this did not work, they got more. Then, they started doing aerial surveys of the area and going to every single water body that seemed to contain stagnant water. And they made it impractical for mosquitos to breed. Then they sprayed, and now it turns out that the mosquitos are slowly disappearing. Coming back to our topic at hand, first you have to get rid of the buggy code/OS that is running out there. At the same time, you put in the law enforcement (must be able to span across countries) controls to punish the people that get caught. Then, I think you can kill off what's left. Just throwing more network engineers and more gear will not get you where you want to go IMHO. It would make quite a few companies a lot of money though. > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Fergie > Sent: Thursday, August 03, 2006 3:54 PM > To: Bora Akyol > Cc: nanog(a)merit.edu > Subject: RE: mitigating botnet C&Cs has become useless > > > I've got news for you. > > To impact the miscreant's bottom-line, then it will take: > > A) Technology, and; > B) Manpower > > It will also take: > > C) Better cooperative efforts. > > - ferg > > > > -- "Bora Akyol" <bora(a)broadcom.com> wrote: > > IMHO, > > This is not a problem we can solve by adding: > > a) technology (other than completely dumping the OS(s) that make this > possible) > b) manpower > > I think it can be solved by reducing the margins in the > miscreant business line or ideally having it have negative margins. > > > I would suggest more specific attention by service providers > > specifically, and everyone in general, perhaps with more "abuse > > services" -related tracks at meetings like NANOG. :-) > > > > Or something along those lines... > <snip> > > I think better to focus on the economics of the business as > part of the abuse track. > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg(at)netzero.net ferg's tech blog: > http://fergdawg.blogspot.com/ > > >

3 2

Routing issues with cox?
by David Hubbard 04 Aug '06

04 Aug '06

Anyone know of something going on with Cox currently? We've had a number of customers report they can't get to us (AS 33260) from Cox (AS 22773). We've tried forcing traffic out different providers of ours and it usually seems to die with Level 3 in DFW, Time Warner Telecom in DFW, Cogent in Atlanta, AT&T in Atlanta, etc. On the Cox side, going on traceroute info from customers, it looks like they might force their outbound on Cogent because everything from them seems to come through that peer even though we prepend that one heavily. Thanks, David

2 1

Report on "Analysis and Recommendations on the Exhaustion of IPv4 Address Space"
by Izumi Okutani 04 Aug '06

04 Aug '06

# Apologies for the duplicates # Dear Colleagues Report on "Analysis and Recommendations on the Exhaustion of IPv4 Address Space" JPNIC has published a report titled "Analysis and Recommendations on the Exhaustion of IPv4 Address Space". The original Japanese version of the report was published on 3 April 2006. It was compiled by JPNIC's "Expert Research Team on Number Resources Utilization" which consists of nine engineers and researchers from the Internet Operations area. It reviews some of the recent studies on the lifetime of IPv4 address, provides analysis on impacts of the exhaustion, and offers recommendations on measures to be taken by all stakeholders. JPNIC with the expert team will keep track of trends concerning IPv4 address exhaustion and revise the report as need arises, in order to provide more precise analysis for further discussions. The translated report is available at: "Analysis and Recommendations on the Exhaustion of IPv4 Address Space" http://www.nic.ad.jp/en/research/IPv4exhaustion_trans-pub.pdf If you have any questions or feedbacks about the report, please email us at <ipv4exh-comment(a)nic.ad.jp> Best Regards, JPNIC IP Department ====================================================== Japan Network Information Center (JPNIC) 6F 2-3-4 Uchikanda, Chiyoda-ku, Tokyo 101-0047 JAPAN TEL: +81-3-5297-2311 FAX: +81-3-5297-2312 =======================================================

1 0

RE: mitigating botnet C&Cs has become useless
by Fergie 03 Aug '06

03 Aug '06

I've got news for you. To impact the miscreant's bottom-line, then it will take: A) Technology, and; B) Manpower It will also take: C) Better cooperative efforts. - ferg -- "Bora Akyol" <bora(a)broadcom.com> wrote: IMHO, This is not a problem we can solve by adding: a) technology (other than completely dumping the OS(s) that make this possible) b) manpower I think it can be solved by reducing the margins in the miscreant business line or ideally having it have negative margins. > I would suggest more specific attention by service providers > specifically, and everyone in general, perhaps with more > "abuse services" -related tracks at meetings like NANOG. :-) > > Or something along those lines... <snip> I think better to focus on the economics of the business as part of the abuse track. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

Re: mitigating botnet C&Cs has become useless
by Fergie 03 Aug '06

03 Aug '06

-- Danny McPherson <danny(a)tcb.net> wrote: [good stuff elided] >I agree that the root of the problem is the miscreants perpetrating >these crimes, and they need to be prosecuted, but the responsibility >falls far wider than the SPs. > >I also accept the references provided by Paul and others, but what's >the near-term alternative? > >-danny > I would suggest more specific attention by service providers specifically, and everyone in general, perhaps with more "abuse services" -related tracks at meetings like NANOG. :-) Or something along those lines... I think the problem(s) have ballooned to the point where everyone is feeling a bit overwhelmed in getting the cooperation needed to take down botnet C&C's, phishing hosts, and other nefarious "services" -- some which try to hide using DNS RR "fast-flux", etc. The whole business of getting cooperation in this area needs much improvement. - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

mitigating botnet C&Cs has become useless
by Gadi Evron 03 Aug '06

03 Aug '06

The few hundred *new* IRC-based C&Cs a month (and change), have been around and static (somewhat) for a while now. At a steady rate of change which maintains the status quo, plus a bit of new blood. In this post I ask the community about what you see, against what we have observed, and try and test my conclusions and numbers against your findings. The subject line "why mitigating botnet C&Cs has become useless" is misleading. It has been useless for a long time, but someone had to hold back the tide, which several online mitigation communities have been doing. Today it has become (close to) completely useless. I will present the case on why that is in my opinion, in a few bullets, and we can discuss what alternatives we have, or if perhaps I am misreading what's going on. *. When a botnet C&C is mitigated, it is immediately re-created on another host on the same ISP or another. *. Most botnet C&Cs are a part of a larger group, such as an IRC network or another, possibly hidden "behind the scenes" network. lusers are being redirected on the spot or reconnect to another host. *. Most botnet C&Cs are a compartmentalized group out of the whole, possibly a sub-group several tiers down. Much like a terrorism cell. *. If the above measures and features fail, most botnets have a secondary control channel with which an immense host can be re-directed. This has been seen back a few years ago. *. Many botnet C&Cs now use fast-flux technology, moving IP addresses quite often. *. When the C&C is taken down, the bot may not jump to a new host, a new one may simply be installed. *. Coordinated take-down of entire networks is extremely difficult, relies on incomplete intelligence and only takes care of the problem for an extremely short period of time until re-assembly. The name of the game is the SPBC: Simple Primitive Botnet Control (C&C). Simple - as it is simple, vs. a complex dynamic control channel. Primitive - old and quite unimpressive. Botnet - d'oh C&C - Command and Control It's simple, we can see most of them with our tools. Primitive, hey, they have been using these for a long long time. It works. As what we mainly did is concentrate on taking the C&C down, as well as academically study how to detect or quantify it, what we achieved was teaching the Bad Guys their business. That is yesterday's news. They are an oiled machine. We don't hurt them any more. Botnet have become mainstream. They are part of sales pitches now. SPBC for the botnet controllers these days relies on proven and tested techniques, concentarting and backing themselves on: Reliability - Efficient and stable. Robust - Easily replaced. Diverse - varying control channels, from DNS, other IRC servers and direct connect to a downloader ready to download a new bot or re-infect a known bad network. Distributed - need I speak of that one? What taking down C&C's does achieve? 1. Coordination on security issues between ISP's, continued and peer-pressure based. Slowly but surely becoming more and more LEO, regulation and vendor-run in comparison to what it used to be. 2. Responsiveness to abuse - gaging ISP response is interesting and shows how interested they are. 3. Feeling good - cleaning the back yard and moving the problem to someone else (another ISP). Hmm, yeah.. not really. In most cases the same ISP's have the same problems month after month. They just make the C&C's "unknwon" vs. "yes, we know where they are". We are now past the point where killing C&Cs has been harmful. It was. These days the only real use a C&C can have for an organization with a network, is to check for infected clients connecting in. When it was harmful, creating the current situation, we were comfortable with it as it helped hold back the immediate problem - which was important by itself. That's my educated opinion, following this since 1996, and gathering statistics for several years, some of which are seen by this community every month. Please, I would love to hear your opinions, disputes and how you find the operational intell on botnet C&Cs useful to this day on networks for mitigation purposes. Then I would like to try and check my facts against your findings as well, and see if my conclusions hold up or if I miscalculated. Please try and limit your answers on this thread (unless you start another) to network mitigation issues. Thank you all for your input. Oh, and I wasn't very accurate. Killing C&Cs these days is still harmful, just that now it doesn't even hold back the tide. Gadi. Note: this is also being sent to the public botnets mailing list.

4 4

Re: APC Matrix 5000 question(s)
by up＠3.am 03 Aug '06

03 Aug '06

On Thu, 27 Jul 2006, Michael J Wise wrote: > On Jul 27, 2006, at 5:10 AM, Ray Van Dolson wrote: > > > In any case, give APC support a holler. > > Definitely. > > > I'm always nervous doing any sort of maintenance on our Symmetra. > > The Symmetra is a completely different animal from the 5000, though. > I <3 the Symmetra. > > Oh yes, one more point... best to check the 5000's battery packs for > heat and bulging, as some of the packs may be about to vent the Hot > Sauce, and cleaning that up is always "Fun". Aloha mai Nai`a! -- "Please > have your Internet License http://kapu.net/~mjwise/ Update: I replaced the batteries today, and indeed, several of the old ones (mostly in the first pack) were split and some had popped a couple of their "sealed" tops. I left for several hours and came back to the house stinking like burning rubber. The new batteries are apparently melting the terminal rubber insulation. I had to throw it back into bypass mode and unplug that pack (the only one with new batteries!) Any ideas to the cause? The status screens looked ok. ("no bad batteries" again) James Smallacombe PlantageNet, Inc. CEO and Janitor up(a)3.am http://3.am =========================================================================

7 7

DNS BIND dispatch errors
by Simon Waters 03 Aug '06

03 Aug '06

The increase in dispatch errors reported by BIND recently is explained by the other ISC here; http://isc.sans.org/diary.php?storyid=1538 So it looks like the error message was right, although some older versions of BIND didn't do a good job of reporting the IP addresses involved. My own experience was the servers mentioned here aren't the only servers doing this rather bizarre behaviour, but it is likely they could account for the increase seen (in association with a spam run causing lookups).

1 0

RE: Good list for VoIP
by John Stuppi (jstuppi) 03 Aug '06

03 Aug '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mike, You can try voipsec(a)voipsa.org: To subscribe or unsubscribe via the World Wide Web, visit http://voipsa.org/mailman/listinfo/voipsec_voipsa.org or, via email, send a message with subject or body 'help' to Voipsec-request(a)voipsa.org You can reach the person managing the list at Voipsec-owner(a)voipsa.org Thanks, John - -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mike Callahan Sent: Thursday, August 03, 2006 8:21 AM To: nanog(a)merit.edu Subject: OT: Good list for VoIP Sorry for the OT post but I'm wondering if anyone can recommend a good list for ISP level VoIP discussion. On that's focus is on technical issues would be preferred. Thanks, M. Callahan -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRNHvX/EVU0zaWQwNEQLquwCeJQzrYfHXumL75krxKCuDAIn6N5AAoPXo VDyt7P6tvrmpXyehRNa90fBK =li6s -----END PGP SIGNATURE-----

1 0

Fwd: [apops] APNIC debogon project]
by Noel 03 Aug '06

03 Aug '06

Hi All, As I recall the no end of problems many of us had when APNIC issued 124/7, I'll get in early and ask that you please be advised of the following and make any required changes to your core equipment. Thanks.. -----Forwarded Message----- To: apnic-announce(a)apnic.net Subject: APNIC debogon project Date: Thu, 03 Aug 2006 10:32:10 +1000 Dear colleagues In January 2006, APNIC received the following IPv4 address ranges from IANA: - 121/8 - 122/8 - 123/8 APNIC has started making allocations from these address ranges. To ensure these ranges are not being accidentally filtered, selected prefixes from each /8 have been announced using AS12654. A reachability test can be done on each test prefix. A list of "pingable" hosts and a daily visibility report for each prefix is available here: http://www.ris.ripe.net/debogon/debogon.html If you need further assistance or have any concerns, please feel free to contact us at <helpdesk(a)apnic.net>.

1 0