Re: advise on network security report
Rick, It would interesting to know how you classify "incidents" in the table below.... - ferg -- Rick Wesson <wessorh@ar.com> wrote: 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. | +-------+-----------+------+-------------------------------------+ -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
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 C&C o hoping glue/fast flux o abusive, vulnerable web servers Should I track other things? I'm always open to new data sources... -rick
On Oct 30, 2006, at 9:23 AM, Rick Wesson wrote:
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 C&C o hoping glue/fast flux o abusive, vulnerable web servers
Some of those are clearly ludicrous to count as "incidents" at all, and some of them aren't obviously a single incident, by any reasonable measure so if you're planning to aggregate them all together into a single count the end result is also going to be worthless. Some other way of aggregating the data might be more useful. (I also suspect that a subjective popularity contest list of providers is not likely to be viewed as operational by many on nanog, though I think some of the underlying data might be). Cheers, Steve
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 C&C o hoping glue/fast flux o abusive, vulnerable web servers
Some of those are clearly ludicrous to count as "incidents" at all
oh? which? i can see some not being clearly incidents, but rather operational states, e.g. a vulnerable server/service. but ludicrous? randy
On Oct 30, 2006, at 9:44 AM, Randy Bush wrote:
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 C&C o hoping glue/fast flux o abusive, vulnerable web servers
Some of those are clearly ludicrous to count as "incidents" at all
oh? which?
i can see some not being clearly incidents, but rather operational states, e.g. a vulnerable server/service. but ludicrous?
Well, the data sources that have a significant false positive rate are going to count many things as "incidents" that are anything but. If sending closed-loop, opt-in email is considered equivalent to hosting a botnet command and control network... the data is meaningless. In the hope of not pulling the blacklist trolls out of the woodwork I'm not going to be more specific as to which of those data sources have noticeable false positive issues, but I'm sure you get my point. Cheers, Steve
participants (4)
-
Fergie
-
Randy Bush
-
Rick Wesson
-
Steve Atkins