Re: advise on network security report
Roland Dobbins wrote: On Oct 30, 2006, at 8:53 AM, Rick Wesson wrote: I'm expecting to post a weekly report once a month to nanog, would this be disruptive? Far better to simply post a pointer to your new list, IMHO, and let folks subscribe if the so choose. As it is, many of these various automated postings to NANOG are mildly annoying to those who aren't interested or who already receive the information in another form. the point of the posting are to generate discussion; the list subscription will be made available for those that desire access to higher frequency of reporting. Whatever service you end up offering, a a full-text RSS or Atom feed would probably be useful, as well. we do CSV for detail reporting and will be posting these directly to the abuse@ mbox for the nextworks we have contacts for. -rick
Re: advise on network security report
Barry Greene (bgreene) wrote: Postings like this to NANOG will not have any impact. So if your goal is instigate action, posting is not going to work. The core data point is the weekly CIDR report. It only works if you have peers using the weekly list to apply peer pressure to the networks listed to act. I beg to differ, wither I aggregate my announcements does not impact the $50B charge identity theft puts on the US economy. would it assist if I associated a dollar value for each bot hosted, we can estimate the number of credit cards stolen per bot and extrapolate in to something with some zeros on it. Sharing summaries to communities like dshield, NSP-SEC, DA, SANs and other security mitigation communities along with a subscription web page that would allow an organization to get enough details to take action. nsp-sec players still won't let us in their sand-box... but we will share to the communities you have enumerated. -rick
advise on network security report
I would appreciate a bit of advise on a service I am about to deploy. I've spoken at different venues (including nanog) on global infection rates of bots and the general degradation of well behaved hosts. I now track around 2.2M abuse events per day and now have the capability to produce reports for the community on which networks have the largest problems. I am prepared to make reports monthly to the community ordering networks by their volume of issues. I'd like some hints of which might be the most valuable to the community. o are hosts counts or issue counts more important o is a 7 or 30 day window sufficient for aggregation? o I'm not repaired for graphs yet so don't go there. o should I post sub-reports for regions, by RIR? o which kinds of abuse are more interesting. I'm expecting to post a weekly report once a month to nanog, would this be disruptive? We have a mailing list set up for weekly reports, once finalized I'll post the location for its list manager. The global report usually has about 6,000+ networks, the top 100 from last week are below. again, thanks for your feedback. -rick Table 1. Networks with abuse, ordered by #incidents +---+---+--+-+ | asn | incidents | cc | left(asname,35) | +---+---+--+-+ | 4134 |517830 | CN | CHINANET-BACKBONE | | 9121 |331955 | EU | TTNet | | 4837 |289984 | CN | CHINA169-Backbone | | 3320 |231516 | DE | Deutsche Telekom AG | | 3352 |211504 | ES | TELEFONICA-DATA-ESPANA Internet Acc | | 5617 |194685 | PL | TPNET | | 3215 |181686 | FR | AS3215 | | 3269 |175858 | EU | ASN-IBSNAZ | | 4766 |129722 | KR | KIXS-AS-KR | | 19262 |125003 | US | Verizon Internet Services | | 8551 |116014 | EU | ISDN-NET-AS | | 3209 | 94981 | DE | UNSPECIFIED | | 3462 | 82089 | TW | HINET | | 9829 | 80538 | IN | BSNL-NIB| | 8151 | 79223 | EU | Uninet S.A. de C.V. | | 8359 | 73640 | RU | MTUONLINE | | 5486 | 65757 | EU | Euronet Digital Communications | | 12322 | 65638 | FR | PROXAD AS for Proxad ISP| | 4788 | 53863 | MY | TMNET-AS-AP | | 9116 | 53375 | IL | Goldenlines main autonomous system | | 4814 | 52712 | CN | CHINA169-BBN| | 22927 | 51899 | AR | Telefonica de Argentina | | 4812 | 46462 | CN | CHINANET-SH-AP | | 1680 | 45848 | IL | NETVISION | | 9105 | 44450 | UK | TISCALI-UK | | 15557 | 42792 | FR | LDCOMNET| | 9498 | 42774 | IN | BBIL-AP | | 8584 | 41914 | US | Barak AS| | 2856 | 41820 | EU | BT-UK-AS| | 13184 | 41688 | DE | HANSENET HanseNet Telekommunikation | | 9318 | 40930 | KR | HANARO-AS | | 12479 | 39009 | EU | UNI2-AS Uni2 Autonomous System | | 6147 | 38716 | US | Telefonica del Peru S.A.A. | | 3243 | 38586 | PT | RIPE NCC ASN block | | 6713 | 35777 | EU | IAM-AS | | 12876 | 35068 | FR | AS12876 | | 6739 | 32639 | ES | ONO-AS | | 8228 | 32352 | FR | CEGETEL-AS CEGETEL ENTREPRISES | | 1267 | 31869 | IT | ASN-INFOSTRADA Infostrada S.p.A.| | 7418 | 30221 | EU | Terra Networks Chile S.A. | | 5462 | 28861 | UK | CABLEINET Telewest Broadband| | 8708 | 28236 | EU | RDSNET | | 5430 | 27245 | DE | FREENETDE | | 7470 | 24729 | TH | ASIAINFO-AS-AP | | 5610 | 24279 | CZ | CZECHTELECOM CZECH TELECOM, a.s | | 16338 | 23956 | ES | AUNA_Telecom-AS | | 4713 | 23650 | JP | OCN NTT Communications Corporation | | 12424 | 22932 | ES | JAZZASN Autonomous System | | 5089 | 21322 | EU | NTL NTL Group Limited | | 17813 | 20792 | IN | MTNL-AP Mahanagar Telephone Nigam L | | 5483 | 20511 | EU | HTC-AS Hungarian Telecom| | 4755 | 19673 | UK | VSNL-AS | | 8764 | 19571 | LT | TELECOMLT-AS| | 28725 | 18369 | CZ |
Re: advise on network security report
Fergie wrote: Rick, It would interesting to know how you classify incidents in the table below any one of the following: o being put on a major DNS black list (spamcop, spamhaus, ahbl etc.) o hosting malware or phishing sites, open proxies o sending LOTS of SPAM, virus o IRC abuse o Botnet CC o hoping glue/fast flux o abusive, vulnerable web servers Should I track other things? I'm always open to new data sources... -rick
Re: Experiences with DDoS platforms...
Hey Ferg, when you get some boxes to play with I'd be happy to help load them with a 10G DDoS; it would be phun... I'd also be interested to work with researchers on instrumenting the attack. I think I know how to pitch one, just never had a willing catcher. I'd especially enjoy it if you could publish your results of such research. best, -rick Fergie wrote: So, it would appear to me that simply analyzing netflow data, etc., at the time of a (D)DoS attack, and then black-holing (by hand) the offending source addresses may not be the most scalable and efficient way of dealing/coping/mitigating/staying-on-the-air during an attack. Of course, depending where you are on the food chain, the resources one is trying to protect, the volume of DDoS traffic, etc, plays into the equation, etc. I was looking to see what opinions folks on the list may have on the DDoS appliance vendor products available -- I'm particularly looking for a stand-alone (or in conjunction with a 'traffic analysis' box) to off-load DoS mitigation -- real-world experiences welcome. Please direct responses to me off-list, or not... Thanks, - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: mitigating botnet CCs has become useless
Mikael Abrahamsson wrote: On Tue, 8 Aug 2006, Simon Waters wrote: However most big residential ISPs must be getting to the point where 10% bandwidth saving would justify buying in third party solutions for containing malware sources. I assume residential ISPs must be worse than [snip] It might not be the right thing, but the economics for the residential ISP it costs a lot to try to be proactive about these things, especially since botnets can send just a little traffic per host and it's hard to even detect. Last sunday at DEFCON I explained how one consumer ISP cost American business $29M per month because of the existence of key-logging botnets. you want to talk economics? Its not complicated to show that mitigating key-logging bots could save American business 2B or 4% of =losses to identity theft -- using FTC loss estimates from 2003 just because an ISP looses some money over transit costs does not equate to the loss american business+consumers are loosing to fraud. sorry, DEFCON slides aren't up anywhere yet. drop me a note if you'd like a copy. -rick
Re: mitigating botnet CCs has become useless
this isn't fun, comments in line. Sean Donelan wrote: On Tue, 8 Aug 2006, Rick Wesson wrote: Last sunday at DEFCON I explained how one consumer ISP cost American business $29M per month because of the existence of key-logging botnets. Why did you attribute responsibility for the cost only to the consumer ISP? How much of the cost should be attributed the PC OEM, or the software developers, or the American business, or the ? Because the numbers are significant. Finding any entity that could provide a choke-point for 4% of business side id-theft is an interesting exercise and of significant value to the community. you want to talk economics? Its not complicated to show that mitigating key-logging bots could save American business 2B or 4% of =losses to identity theft -- using FTC loss estimates from 2003 What are the economics of American businesses mitigating key-logging bots? there is no detectable mitigation, the slope of the infection rate continues to rise. How much security would you get for an additional $20 per year per on-line user? Spending more than the losses wouldn't save American business money. depends on how it is spent -rick
Re: Detecting parked domains
Parked: A domain hosted by a middle-man for the sole purpose of generating revenue from pay-per-click advertising. Characterized by having no content of value. This definition *might* work for NANOG, but my parking friends would disagree with the above. Florian Weimer wrote: * Sean Donelan: Has anyone come up with a quick method for detecting if a domain name is parked, but is not being used except displaying ads? AFAICT, the main challenge is to define what parked means in the context of your application.
Re: Detecting parked domains
I have a large list of parked domains how would you like to query it and why do you want to? -rick Sean Donelan wrote: Has anyone come up with a quick method for detecting if a domain name is parked, but is not being used except displaying ads? I'm hoping there is other method besides chasing a list of constantly changing IP addresses being used by the parking advertising companies.
Re: Sitefinder II, the sequel...
Gerry, I sat on the Security and Stability committee for ICANN and was part of the folks that reviewed SiteFinder. OpenDNS is not SiteFinder; Give them a try, the DNS resolution is blazing fast and they do fix up the most common typos. One thing massively different between openDNS and SiteFinder is that you have choice -- the choice to use them. IMHO many will choose to use OpenDNS because it is fast and can offer protections you just can't get from running your own resolver. best, -rick Gerry Boudreaux wrote: It is not VeriSign this time. For those who have not yet seen this: http://www.opendns.com/ They will 'correct' your spelling mistakes for you. From their FAQ: -- Why is OpenDNS smarter? We fix typos in the URLs you enter whenever we can. For example, if you're using OpenDNS craigslist.og will lead directly to craigslist.org.If we're not sure what to do with an error, we provide search results for you to choose from. How does OpenDNS make money? OpenDNS makes money by offering clearly labeled advertisements alongside search results on error pages. OpenDNS will provide additional services on top of its enhanced DNS service. ---
Re: Sitefinder II, the sequel...
Personally I think openDNS is an idea whose time has come and that Dave Ulevitch and is crew are going to hit one out of the ballpark with this. Have you switched your company over yet? yes, and the thing that pisses me off, is that it does seem faster. -rick
Re: wrt joao damas' DLV talk on wednesday
... and alice has been working on deploying the .org DNSSEC testbed for 6 months now. Thus far my experence with deploying DNSSEC is: its just hard, not fun and for a lack of a better word... it SUCKS. In the last 6months since we deployed it, not one sole has clicked on the [now broken] _SECURE DOMAIN_ link to enable .ORG dnssec capabilities. I know we are a tiny registrar but none of our clients thought it important enough to even try clicking on the _SECURE DOMAIN_ link. So, even DLV is going to take a tremendous marketing effort to get folks to differentiate it from LOCK_DOMAIN which merely prevents the domain from being updated or transfered. DLV is a huge task so be supportive because it will probably fail just like DNSSEC is ...but we might just learn something. -rick Paul Vixie wrote: can you say does not scale? Indeed. this is why we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships.
howto deploy DNSSEC [was: Re: wrt joao damas' DLV talk on wednesday]
I'm ashamed to call myself a participant in NANOG, IETF and ICANN. every once in a while I get to participate in something that moves forward the network just a bit; please refrain from this thread -- a few folks are attempting to move DNSSEC ahead; we will fail, but would appreciate any constructive criticism on the pitfalls to deploy before we are all dead. -rick
Re: 2006.06.07 NANOG-NOTES Lightning talk notes
thanks for taking (and posting) notes matt! [snip] NEXT: Rick Wesson, Support Intelligence [hehe] Understanding abuse, aggregate it, push it back to operators, let them know what they're doing to other people. [no slides, he does a live presentation of his tool] How do I believe you? realtime data visualization, Feb 8th, 2006 visualization. 130 different data sources, 90% passive; 10,000 domain aggregated spam trap, very evil SMTP that filters and bans IP for some time. 1.2million events per day aggregated, about 700,000 unique IPs for the global internet. BGP peers, aggregate based on announcements made. Put into tool so network operators can visualize their prefixes, drill in, and see abuse each prefix generates. hover over point, it shows the operator, IP address, and what the problem was (spam, insecure web server, etc) This shows problem areas that need to be addressed! disseminate this information, help ISPs clean up their networks. Can also pass along information of abuse that has happened to you. If you have an AS, he can tell you what your AS has been used for, abused for, owned, etc. email him for more info...except he didn't list his email info. ^_^; my bad. [EMAIL PROTECTED] or [EMAIL PROTECTED] works. always happy to help. -rick
Re: a fun hijack: 1/8, 2/8, 3/8, 4/8, 5/8, 7/8, 8/8, 12/8 briefly announced by AS 23520 (today)
Todd Underwood wrote: josh, all, these are always fun. these events continue to be a problem for all of us. Check out the IAR for Potential Prefix Hijacks and if you're coming to this more than 24 hours after the post, do a search on AS 23520 as the hijacking AS. here are some other details that we saw about this event. - as of two days ago 23520 only originated 26 prefixes - yesterday they originated 2821 prefixes. this event was about a lot more than a few /8s. - we still see them originating 140 prefixes, as of this afternoon (EDT). here's a list of the prefixes that we saw them originate yesterday that were not originated two days ago. the average amount of time a peer of renesys's saw those prefixes routed was about 80 seconds. This is what/when we saw, the middle column is how long we observed the route (HH:MM:SS) before it was withdrawn. if anyone wants a csv dump of the raw data drop me a note off-list. -rick +--+---+-+ | prefix | elapsed | announced | +--+---+-+ | 63.245.0.0/17| 34:06:08 | 2005-08-17 10:41:18 | | 63.245.0.0/17| 69:49:31 | 2005-08-23 23:01:32 | | 63.245.0.0/17| 03:41:18 | 2005-08-26 20:52:52 | | 63.245.1.0/24| 34:06:10 | 2005-08-17 10:41:16 | | 63.245.1.0/24| 69:49:25 | 2005-08-23 23:01:38 | | 63.245.1.0/24| 03:41:17 | 2005-08-26 20:52:53 | | 63.245.2.0/24| 34:06:10 | 2005-08-17 10:41:16 | | 63.245.2.0/24| 69:49:25 | 2005-08-23 23:01:38 | | 63.245.2.0/24| 03:41:17 | 2005-08-26 20:52:53 | | 63.245.7.0/24| 34:06:10 | 2005-08-17 10:41:16 | | 63.245.7.0/24| 69:49:25 | 2005-08-23 23:01:38 | | 63.245.7.0/24| 03:41:17 | 2005-08-26 20:52:53 | | 63.245.30.0/23 | 33:59:39 | 2005-07-07 14:47:34 | | 63.245.30.0/23 | 00:52:30 | 2005-07-09 01:22:23 | | 63.245.30.0/23 | 00:52:49 | 2005-07-09 02:45:11 | | 63.245.30.0/23 | 00:00:29 | 2005-07-09 04:53:35 | | 63.245.30.0/23 | 17:31:39 | 2005-07-09 05:45:11 | | 63.245.30.0/23 | 02:52:10 | 2005-07-10 00:16:46 | | 63.245.30.0/23 | 24:11:12 | 2005-07-10 04:33:23 | | 63.245.30.0/23 | 42:52:31 | 2005-07-25 16:13:55 | | 63.245.30.0/23 | 159:21:36 | 2005-07-28 00:35:48 | | 63.245.30.0/23 | 03:20:50 | 2005-08-04 18:00:08 | | 63.245.30.0/23 | 34:06:10 | 2005-08-17 10:41:16 | | 63.245.30.0/23 | 48:55:07 | 2005-08-18 20:48:22 | | 63.245.30.0/23 | 34:19:50 | 2005-08-23 23:01:38 | | 63.245.30.0/23 | 56:19:24 | 2005-08-25 10:21:32 | | 63.245.30.0/23 | 85:35:18 | 2005-08-27 19:57:29 | | 63.245.30.0/23 | 00:07:38 | 2005-10-18 23:26:11 | | 63.245.32.0/21 | 13:20:11 | 2005-07-25 16:13:50 | | 63.245.46.0/23 | 33:59:41 | 2005-07-07 14:47:32 | | 63.245.46.0/23 | 02:11:56 | 2005-07-09 01:47:45 | | 63.245.46.0/23 | 00:15:43 | 2005-07-09 04:38:48 | | 63.245.46.0/23 | 21:29:00 | 2005-07-09 05:39:56 | | 63.245.46.0/23 | 23:12:13 | 2005-07-10 04:44:19 | | 63.245.46.0/23 | 00:00:30 | 2005-07-11 05:46:09 | | 63.245.46.0/23 | 39:24:30 | 2005-07-25 16:13:54 | | 63.245.46.0/23 | 02:58:40 | 2005-07-27 08:08:41 | | 63.245.46.0/23 | 76:59:42 | 2005-07-28 00:35:47 | | 63.245.46.0/23 | 61:11:01 | 2005-07-31 06:35:37 | | 63.245.46.0/23 | 04:42:10 | 2005-08-04 18:00:08 | | 63.245.46.0/23 | 07:12:53 | 2005-08-04 23:08:36 | | 63.245.46.0/23 | 34:06:12 | 2005-08-17 10:41:14 | | 63.245.46.0/23 | 48:47:07 | 2005-08-18 20:48:22 | | 63.245.46.0/23 | 08:56:24 | 2005-08-20 22:40:29 | | 63.245.46.0/23 | 69:49:26 | 2005-08-23 23:01:37 | | 63.245.46.0/23 | 03:41:18 | 2005-08-26 20:52:52 | | 63.245.46.0/23 | 18:06:19 | 2005-08-27 00:34:37 | | 63.245.46.0/23 | 85:51:37 | 2005-08-27 19:41:10 | | 63.245.104.0/21 | 13:20:11 | 2005-07-25 16:13:50 | | 64.86.178.0/23 | 05:04:05 | 2005-06-30 11:04:59 | | 64.86.178.0/23 | 16:56:40 | 2005-07-04 15:39:30 | | 64.86.178.0/23 | 02:26:38 | 2005-07-05 09:33:20 | | 64.86.178.0/23 | 03:05:53 | 2005-07-05 12:41:03 | | 64.86.178.0/23 | 00:56:06 | 2005-07-05 16:47:32 | | 64.86.178.0/23 | 00:57:06 | 2005-07-05 18:17:36 | | 64.86.178.0/23 | 02:47:55 | 2005-07-05 21:38:13 | | 64.86.178.0/23 | 02:07:35 | 2005-07-20 12:27:48 | | 64.86.178.0/23 | 19:29:23 | 2005-07-28 00:35:47 | | 64.86.178.0/23 | 15:49:49 | 2005-08-04 18:00:08 | | 64.86.178.0/23 | 34:06:12 | 2005-08-17 10:41:14 | | 64.86.178.0/23 | 69:49:26 | 2005-08-23 23:01:37 | | 64.86.178.0/23 | 03:41:18 | 2005-08-26 20:52:52 | | 65.217.50.0/24 | 05:04:05 | 2005-06-30 11:04:59 | | 65.217.50.0/24 | 16:56:40 | 2005-07-04 15:39:30 | | 65.217.50.0/24 | 02:26:38 | 2005-07-05 09:33:20 | | 65.217.50.0/24 | 03:05:53 | 2005-07-05 12:41:03 | | 65.217.50.0/24 | 00:56:06 | 2005-07-05 16:47:32 | | 65.217.50.0/24 | 00:57:06 | 2005-07-05 18:17:36 | | 65.217.50.0/24 | 02:47:55 | 2005-07-05 21:38:13 | | 65.217.50.0/24 | 02:07:35 | 2005-07-20 12:27:48 | | 65.217.50.0/24 |
Re: Are botnets relevant to NANOG?
Some people need whatever bandwidth they can get for ranting. Of course routing reports, virus reports and botnet bgp statistics take away a lot of valuable bandwidth that could otherwise be used for nagging. On the other hand without Gadi's howling for the wolves those wolves might be lost species and without the wolves all the nagging and ranting would make less fun. lets see, should we be concerned? here are a few interesting tables, the cnt column is new IP addresses we have seen in the last 5 days. The first table is Tier-2 ASNs as classified by Fontas's ASN Taxonomy paper [1] The second table is Universities. The ASN concerned are just in the announced by orgs in USA as to imply that they should be on NANOG. Let me say it again the counts are NEW observations in the last 5 days. also note I'm not Gati, and I've got much more data on everyones networks. -rick New compromised unique IP addresses (last 5 days) Tier-2 ASN +---++---+ | asnum | asname | cnt | +---++---+ | 19262 | Verizon Internet Services | 35790 | | 20115 | Charter Communications | 4453 | | 8584 | Barak AS | 3930 | | 5668 | CenturyTel Internet Holdings, Inc. | 2633 | | 12271 | Road Runner| 2485 | | 22291 | Charter Communications | 2039 | | 8113 | VRIS Verizon Internet Services | 1664 | | 6197 | BellSouth Network Solutions, Inc | 1634 | | 6198 | BellSouth Network Solutions, Inc | 1531 | | 9325 | XTRA-AS Telecom XTRA, Auckland | 1415 | | 11351 | Road Runner| 1415 | | 6140 | ImpSat | 1051 | | 7021 | Verizon Internet Services | 961 | | 6350 | Verizon Internet Services | 945 | | 19444 | CHARTER COMMUNICATIONS | 845 | +---++---+ Universities, new unique ip last 5 days +---++-+ | asnum | left(asname,30)| cnt | +---++-+ |14 | Columbia University| 93 | | 3 | MIT-2 Massachusetts Institute | 45 | |73 | University of Washington | 25 | | 7925 | West Virginia Network for Educ | 24 | | 4385 | RIT-3 Rochester Institute of T | 20 | | 23369 | SCOE-5 Sonoma County Office of | 19 | | 5078 | Oklahoma Network for Education | 18 | | 3388 | UNM University of New Mexico | 18 | |55 | University of Pennsylvania | 13 | | 159 | The Ohio State University | 12 | | 104 | University of Colorado at Boul | 12 | | 4265 | CERFN California Education and | 11 | | 693 | University of Notre Dame | 10 | | 2900 | Arizona Tri University Network | 9 | | 2637 | Georgia Institute of Technolog | 9 | +---++-+ [1] http://www.ece.gatech.edu/research/labs/MANIACS/as_taxonomy/
Re: Are botnets relevant to NANOG?
John, The short answer is no. The longer answer is that we haven't found a reliable way to identify dynamic blocks. Should anyone point me to an authoritative source I'd be happy to do the analysis and provide some graphs on how dynamic addresses effect the numbers. also note that we are using TCP fingerprinting in our spamtraps and expect to have some interesting results published in the august/sept time frame. We won't be able to say that a block is dynamic but we will be able to better understand if we talk to the same spammer from different ip addresses and how often those addresses change. I believe that understanding our tcp fingerprinting of spam senders might be more interesting and relevant to NANOG than how dynamic address assignments discounts the numbers i posted earlier. -rick John Kristoff wrote: On Fri, 26 May 2006 10:21:10 -0700 Rick Wesson [EMAIL PROTECTED] wrote: lets see, should we be concerned? here are a few interesting tables, the cnt column is new IP addresses we have seen in the last 5 days. Hi Rick, What I'd be curious to know in the numbers being thrown around if there has been any accounting of transient address usage. Since I'm spending an awful lot of time with DNS these days, I'll actually provide a cite related to that (and not simply suggest you just quote me :-). See sections 3.3.2 and 4.4 of the following: Availability, Usage and Deployment Characteristics of the Domain Name System, Internet Measurement Conference 2004, J. Pang, et. al At some point transient address pools are limited and presumably so are the possible numbers of new bots, particularly within netblocks. Is there any accounting for that? Shouldn't there be? What will the effect of doing that be on the numbers? John
Re: Are botnets relevant to NANOG?
for this community would trend analysis with the best of who is getting better and the worst of who is getting worse and some baseline counts be enough for this group to understand if the problem is getting better. I am suggesting that NANOG is an appropriate forum to publish general stats on who the problem is getting better/worse for and possibly why things got better/worse. I'd like to see a general head nod that there is a problem and develop some stats so we can understand if it is getting better or worse. -rick Fergie wrote: Not effective against botnets. Think of it this way, thousands of compromised hosts (zombies), distributed to the four corners of the Internet, hundreds (if not thousands) of AS's -- all recieving their instructions via IRC from a CC server somewhere, that probably also may change due to dynamic DNS, or pump-and-dump domain registrations, or any other various ways to continually move the CC. Simply going after (what may _seem_to_be_) the last-hop router is like swinging a stick after a piñata that you can't actually reach when you are blind-folded. :-) - ferg -- Peter Dambier [EMAIL PROTECTED] wrote: Just an afterthought, traceroute and take the final router. I guess for aDSL home users you will find some 8 or 11 routers in germany. My final router never changes. Of course there can hide more than one bad guy behind that router. [snip] -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: Are botnets relevant to NANOG?
I am saying I am reading the OARC comments and this is sort of what it fees like. As much as Gadi seems to appropriate others credit, Randy Vaugh and him have been doing this work for some time and deserves some credit so I'd say have you spoken to them about how to make their report better yet instead of create more. Yes, we have worked with Gati and Randy Vaugh; infact randy helped me out today; thanks randy! There is a difference in how Randy/Gati collect data and how we collect data. The stuff we publish are from numerous dns based realtime blacklists and spam traps we run. Other folks black-hole botnets and capture data. We both come up with a dataset that overlaps but we don't yet know by how much. So our data is another view using a different methodology and isn't supposed to be better but confirming of where the problem is and estimates of its magnitude. -rick
FYI: reg-ops now becoming fully operational
Through 2005, the reg-ops (Registrar Operations) mailing list which was established after the first Panix incident, was working by trial and error, learning from past mistakes, formalizing reporting guidelines and operating procedures. The mailing list now holds representatives from most of the big registrars. reg-ops also holds liaisons to NSP-SEC, DA/MWP, ICANN, SSAC, NANOG and the root servers. Other than the registrars, there are also a limited number of vetted individual from the anti-spam, anti-phishing and security industry. The purpose of the list is to relay reliable information in real-time from the industry to registrars on issues such as scams, phishing, etc. Real-time issues are handled with care while other reports can be made digested, periodically. The list is mostly operational and therefore there is not much chatter. However, security and operational issues which concern registrars or cooperation/information sharing happens when it is needed. The list is not open to the public, and subscription requires vetting. Please contact me or Gadi Evron [EMAIL PROTECTED] directly to be added to the group. Thanks, -rick
gao contact
I lost the contact details of the GAO rep, i believe his name is Vijay D'Souza of the U.S. Govt. Accountability Office, if anyone has is contact details could you drop them to me off list. thanks, -rick
Whois Query Changes in the .ORG Registry, 20 August 2005 (2-day Notice)]
FYI -rick Original Message Subject: [Org-Registrars] Whois Query Changes in the .ORG Registry, 20 August 2005 (2-day Notice) Date: Thu, 18 Aug 2005 13:47:36 -0400 From: PIR Technical Support [EMAIL PROTECTED] To: [EMAIL PROTECTED] Dear Registrars, Please be advised that on 20 August 2005 between 15:00 and 17:00 UTC, the .ORG Whois (including port 43 and www.pir.org) is scheduled for downtime and will be unavailable. Please note that the .ORG Registry System will continue to operate normally and the Shared Registration System (SRS) and the Web-based Admin Interface will remain available. Registering and manipulating domain names and other registry objects will be possible. Domains will continue to resolve normally. During this downtime, PIR will implement the following changes to the Whois function for the .ORG Registry System. 1. Whois access for public Port 43 will be restricted to 4 queries per minute per unique IP address. 2. Registrars will be provided with additional access to Whois via a dedicated Whois server, whois2.publicinterestregistry.net. These changes are being made in response to the requests we have received from registrars and registrants to minimize the potential for data mining the .ORG Registry's Whois records. Whois Access for Public Port 43 *** To reduce abusive use of the public Whois and ensure access for legitimate users, PIR is executing changes necessary to restrict Whois access to the public Port 43 to a maximum of 4 queries per minute per IP address. When a user exceeds the lookup quota allocated, the system will respond with an appropriate message. Registrar Specific Whois Access All .ORG registrars will be provided with a dedicated Whois access server, whois2.publicinterestregistry.net. Registrars will still be able to access the public Port 43 Whois server, though the 4 queries per minute limitation will exist if this access mechanism is used. It is recommended that registrars utilize the separate dedicated Whois server that will be explicitly for registrar use. This access will allow registrars to have a less restrictive access of 50 queries per minute per source IP to Whois information. This dedicated Whois server will be available from a different hostname/IP address than the public Whois service. Additional information regarding registrar access to the dedicated Whois server and IP/Subnet requirements are located at https://www.pir.org/registrars/registrar_relations/faqs/whois_limitation. Registrars may choose to utilize both the public Whois on Port 43 and the separate dedicated server concurrently. Should you have any questions, please contact PIR Technical Support. Sincerely, PIR Technical Support [EMAIL PROTECTED] +1.416.646.3308
Re: botnet reporting by AS - what about you?
I'd personally love more reporting services that will actually disclose information to the ISPs who can actually take action to help straighten out their customers. We have far too many people who sit around wringing their hands about how horrible the botnets are, but who won't tell anyone who can do anything about it out of a paranoid sense of security. I'm not sure this is the best way to go about that though. :) ok. I'm working on the following service and would like to know if there is interest to participate. just drop a not off list if you want to play. I've been producing daily reports for about 60 ASes in a report via email. It is taking significant cycles to produce and I could only hand another 60 or so networks. Since this won't scale for me I've decided to do near real-time reports over jabber the idea is to publish reports in the following style: anti phishing reports go to the Domain Registrar and AS manager for the IP space hosting the phish site. botnets, virus infectors, open proxies etc the IP manager get notified. spamertisements, spam senders will notify the registrar the reports are text, human readable RFC-822 style headers. I should have the signup page done next week, i should publish it in this notice but I'm just looking for feedback if doing the above is something the community would participate in. I'd like something that scales and what I've done thus far just won't scale. comments (flames?) please. -rick
Re: Real-time WHOIS for .COM
Joe Abley wrote: On 10 Aug 2005, at 06:36, Florian Weimer wrote: Is there some kind of real-time WHOIS for .COM (and friends) which allows you to determine at least the corresponding registrar? whois.crsnic.net? the issue is that VGRS does not even allow a registrar to find out this information real-time. Other registries publish this information in the whois and also make it available to registrars through EPP real-time. RRP and the VeriSign EPP implementation DO NOT allow a registrar to inspect other registrars object (though other registres do) don't expect the powers that be to assist anyone in security issues. the average length of a phishing e-mail spam last some 45 minues, com,net whois is updated ever 24 hours. -rick
networks with many issues
I've come across a few requests for reports with over 10,000 issues. for the net ops folks that might have huge blocks with many issues -- what is the most relivant information? Also, how does one go about solving a large set of issues across a huge address space? Basickly I'm wondering if I can't build some tools to make life easyer and use the reports as an input to the tools. Also I'd be interested in how large reports should be broken down. I have the issue, address, reverse dns, source and timestamp. would it be best to group the report by issue type. The issues I am track are Open Proxy (http, socks, other) Website with vunerabilities Spam source( spammed honney pot, spamtrap) Open Relay (smtp) Understand the timestamp is the time I saw the issue from the RBL. I import data at best hourly and the DNSRBLs don't all have timestamps for their data. I am generaly interested in understanding how to produce information and tools that the large operaters can utilize effectively. I'd appreciate any thoughts and ideas on how to hande these problems. -rick
Re: compromized host list available
Todd Vierling wrote: Certainly, I'd *love* to see a neatly cross referenced list for a few unnamed cesspools who refuse to police their networks, in order to ostracize them for it in public, but that's not the purpose of these reports a personal flaw of mine, is that I tend in this direction, my first impulse was to post a list of all the networks and their rate in infection. I'm doing my best to be productive and nice. -rick
compromized host list available
Folks, I've developed a tool to pull together a bunch of information from DNSRBLs and mix it with a BGP feed, the result is that upon request I can generate a report of all the compromised hosts on your network as seen by various DNSRBLs. reports are available daily in pdf, text, csv, and excel. they are all a bit chunky but should be helpful. contact me off list, if you would like to get a daily report for your ASN. You will be required to prove you are associated with and responsible for the ASN you want a report for. The report are free so this isn't a commercial =) honestly I hope the stuff helps. -rick
