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 | CZ-EUROTEL-AS AS of Eurotel Praha | | 6830 | 18360 | HU | UPC | | 12542 | 17893 | PT | TVCABO Autonomous System | | 9299 | 17854 | PH | IPG-AS-AP | | 18101 | 17325 | IN | RIL-IDC Reliance Infocom Ltd Intern | | 3257 | 16918 | DE | TISCALI-BACKBONE | | 1257 | 16418 | FI | TELE2 AB | | 8881 | 15944 | DE | VERSATEL | | 5713 | 15566 | XX | Telkom SA Ltd. | | 6855 | 15420 | SK | SK SLOVAK TELECOM, AS6855 | | 9304 | 15311 | HK | HUTCHISON-AS-AP | | 5391 | 14937 | EU | T-HT T-Com Croatia Internet network | | 9583 | 14785 | IN | SIFY-AS-IN | | 209 | 14678 | US | Qwest | | 22047 | 14499 | XX | VTR BANDA ANCHA S.A. | | 6849 | 14419 | EU | UKRTELNET | | 24863 | 13616 | EU | LINKDOTNET-AS LINKdotNET AS number | | 8167 | 13184 | BR | TELESC - Telecomunicacoes de Santa | | 20838 | 12898 | ES | YIF-AS | | 6400 | 12563 | XX | Codetel | | 2860 | 12467 | PT | NOVIS Novis Telecom, S.A. | | 13285 | 12347 | UK | OPALTELECOM-AS | | 18403 | 12230 | VN | FPT-AS-AP The Corporation for Finan | | 7132 | 12031 | US | SBC Internet Services | | 20115 | 11683 | US | Charter Communications | | 8452 | 11507 | EU | TEDATA TEDATA | | 4230 | 11385 | BR | Embratel | | 5384 | 10946 | EU | EMIRATES-INTERNET | | 1221 | 10629 | AU | ASN-TELSTRA | | 28573 | 10475 | BR | NET Servicos de Comunicao S.A. | | 8866 | 10434 | BG | BTC-AS | | 9506 | 10126 | SG | MAGIX-SG-AP | | 8997 | 10123 | RU | ASN-SPBNIT SPBNIT-RU Autonomous Sys | | 8404 | 9941 | EU | CABLECOM | | 7693 | 9719 | TH | COMNET-TH | | 12880 | 9663 | IR | DCI-AS | | 6057 | 9432 | XX | Administracion Nacional de Telecomu | | 8402 | 9224 | RU | CORBINA-AS | | 6478 | 8943 | XX | AT&T WorldNet Services | | 5603 | 8913 | SI | SIOL-NET SiOL Internet d.o.o. | | 6327 | 8912 | CA | Shaw Communications Inc. | | 3303 | 8823 | CH | SWISSCOM | | 7552 | 8770 | VN | VIETEL-AS-AP Vietel Corporation | | 11427 | 8757 | XX | Road Runner | | 5466 | 8736 | IE | EIRCOM Eircom | | 6799 | 8634 | GR | OTENET-GR OTEnet S.A. Multiprotocol | | 10318 | 8526 | XX | CABLEVISION S.A. | +-------+-----------+------+-------------------------------------+
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. Whatever service you end up offering, a a full-text RSS or Atom feed would probably be useful, as well. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice Any information security mechanism, process, or procedure which can be consistently defeated by the successful application of a single class of attacks must be considered fatally flawed. -- The Lucy Van Pelt Principle of Secure Systems Design
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
On Oct 31, 2006, at 3:45 PM, Rick Wesson wrote:
the point of the posting are to generate discussion;
I believe there are those who would argue that there's already a surfeit of discussion on NANOG, quite a bit of it irrelevant and of little interest to many subscribers. Posting stats and reports to a list which contains people who may not be interested in same often results in those stats and reports being filtered out and ignored. Posting a pointer to said stats and lists so that interested parties can subscribe if they so choose guarantees a community of common interests to whom discussion of the topic(s) at hand will come naturally, without the need for artificial stimulus. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice Any information security mechanism, process, or procedure which can be consistently defeated by the successful application of a single class of attacks must be considered fatally flawed. -- The Lucy Van Pelt Principle of Secure Systems Design
On Tue, 31 Oct 2006, Rick Wesson wrote:
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.
whichever notification method you use you need to include information that the abuse@ address folks can actually use. Saying: "machine 1.2.3.4 sent spam" isn't useful, however sending: -----------------------------example--------------------- machine 1.2.3.4 delivered this spam: <full spam mail with headers> -----------------------------end example---------------- is useful... Extend that to virus/trojan/bot/C&C info of course (send logs of the abuse). If you don't provide this there is no reasonable way to affect change. Also, make sure that whatever you send is machine parsable, it'd be great to send things in some 'standards compliant' manner as well (INCH perhaps?) sending an email that a human has to process will get that email deleted/ignored/not-processed-to-your-satisfaction. I also believe that since you are aiming at something machine parseable you should submit one email per 'incident' you are reporting, that way abuse@ folks can judge the volume of the problem in a fairly simple manner. it's just an opinion or 3... :) Oh, and as Scott said, pleaes tag the subject so it can get procmail'd appropriately. -Chris
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. 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. Also, posting too much hear just helps the criminals/miscreants. Some of the better ones who have any clue can be assumed to be on NANOG. They would love details on how well their tools are working and which ones are going under the detection radar.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Rick Wesson Sent: Monday, October 30, 2006 8:53 AM To: nanog@merit.edu Subject: 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 | CZ-EUROTEL-AS AS of Eurotel Praha | | 6830 | 18360 | HU | UPC | | 12542 | 17893 | PT | TVCABO Autonomous System | | 9299 | 17854 | PH | IPG-AS-AP | | 18101 | 17325 | IN | RIL-IDC Reliance Infocom Ltd Intern | | 3257 | 16918 | DE | TISCALI-BACKBONE | | 1257 | 16418 | FI | TELE2 AB | | 8881 | 15944 | DE | VERSATEL | | 5713 | 15566 | XX | Telkom SA Ltd. | | 6855 | 15420 | SK | SK SLOVAK TELECOM, AS6855 | | 9304 | 15311 | HK | HUTCHISON-AS-AP | | 5391 | 14937 | EU | T-HT T-Com Croatia Internet network | | 9583 | 14785 | IN | SIFY-AS-IN | | 209 | 14678 | US | Qwest | | 22047 | 14499 | XX | VTR BANDA ANCHA S.A. | | 6849 | 14419 | EU | UKRTELNET | | 24863 | 13616 | EU | LINKDOTNET-AS LINKdotNET AS number | | 8167 | 13184 | BR | TELESC - Telecomunicacoes de Santa | | 20838 | 12898 | ES | YIF-AS | | 6400 | 12563 | XX | Codetel | | 2860 | 12467 | PT | NOVIS Novis Telecom, S.A. | | 13285 | 12347 | UK | OPALTELECOM-AS | | 18403 | 12230 | VN | FPT-AS-AP The Corporation for Finan | | 7132 | 12031 | US | SBC Internet Services | | 20115 | 11683 | US | Charter Communications | | 8452 | 11507 | EU | TEDATA TEDATA | | 4230 | 11385 | BR | Embratel | | 5384 | 10946 | EU | EMIRATES-INTERNET | | 1221 | 10629 | AU | ASN-TELSTRA | | 28573 | 10475 | BR | NET Servicos de Comunicao S.A. | | 8866 | 10434 | BG | BTC-AS | | 9506 | 10126 | SG | MAGIX-SG-AP | | 8997 | 10123 | RU | ASN-SPBNIT SPBNIT-RU Autonomous Sys | | 8404 | 9941 | EU | CABLECOM | | 7693 | 9719 | TH | COMNET-TH | | 12880 | 9663 | IR | DCI-AS | | 6057 | 9432 | XX | Administracion Nacional de Telecomu | | 8402 | 9224 | RU | CORBINA-AS | | 6478 | 8943 | XX | AT&T WorldNet Services | | 5603 | 8913 | SI | SIOL-NET SiOL Internet d.o.o. | | 6327 | 8912 | CA | Shaw Communications Inc. | | 3303 | 8823 | CH | SWISSCOM | | 7552 | 8770 | VN | VIETEL-AS-AP Vietel Corporation | | 11427 | 8757 | XX | Road Runner | | 5466 | 8736 | IE | EIRCOM Eircom | | 6799 | 8634 | GR | OTENET-GR OTEnet S.A. Multiprotocol | | 10318 | 8526 | XX | CABLEVISION S.A. | +-------+-----------+------+-------------------------------------+
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
On Tue, 31 Oct 2006, Rick Wesson wrote:
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.
I experimented with a lot of topics on NANOG which the charter suggests, and found that botnets and $-value only work if they directly impact an ISP (not its users or immense corporate networks), meaning - something which helps/stops an ISP from running. I.e., $$$ loss to the ISP. $ value to the US economy just fascilitates faster move toward the usual and inevitable forking of the thread and flaming.
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.
You heard what people here want/don't want, do your thing. From my experience, you also got about 10-20 emails off-list, in support. Most flames come on-list. Openly available data that will show us which networks we need to worry about will be valuable. In the C&C report we now have "networks with 100% resolved". Two years ago we wouldn't have even considered that category. We didn't even consider using exact numbers due to "help bad guys scare". We quantified it, found out what's useful (what ISPs want/ISPs REALLY don't want), and what would be useless. Of your data, do you have information which can tell us what ISPs keep sending out spam despite of continued listing/reporting? Can you tell us what ISPs do real good work? A not-too-often coming report would be very interesting, especially because it is public, if you can make it reliable. For more exact and regular figures, I'd say go with a private feed. It is possible we are all wrong. Start with once a month and grow to even once a day if we find it's just what we have all been looking for.
-rick
Gadi.
On Tue, 31 Oct 2006 17:02:15 PST, Rick Wesson said:
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.
Well.. figure that if you're charging somebody by the megabyte for transit, there *is* a positive dollar value per bot hosted. Maybe that's the tactic to take with some of the more bot-infested cable providers - if they aren't 100% settlement-free, point out the cost savings at their exchanges if their outbound traffic drops because their bots aren't spewing.....
Hint, hint, hint. When the abuse and security folks at ISPs give suggestions on how to best work with them, its sometimes a good idea to listen. If you just want to shout "You Suck" at them, please have a seat in the waiting room and someone will be with you later, possibly before the heat death of the universe. If you pay an ISP enough money, you're paying for the right to shout You Suck at progressively higher level executives. ISP security and abuse folks generally know how bad the problems are. That isn't useful to getting their jobs done. They usually have better information about how bad it is than most third-parties. ISP security and abuse teams already receive reports from almost every group in existence. After they process the high priority work, e.g. court orders from countries around the world, reports from customers, etc; figuring out how to make the security and abuse teams lives easier is the key to getting your complaints to the top of the pile. Rankings of other ISPs doesn't change their workload. Although every ISP security and abuse group is different, I think most of them have their favorite third-party sources. Listening to why they like using particular resources over other third-party resources could help make your third-party resource more relevant to their work. "You Suck" doesn't help them get home any earlier.
participants (8)
-
Barry Greene (bgreene) -
Chris L. Morrow -
Gadi Evron -
Jim Popovitch -
Rick Wesson -
Roland Dobbins -
Sean Donelan -
Valdis.Kletnieks＠vt.edu