BGP Update Report
BGP Update Report Interval: 04-Feb-08 -to- 06-Mar-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS949894122 1.6% 76.0 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - AS24731 68420 1.2% 937.3 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 3 - AS958354286 0.9% 45.2 -- SIFY-AS-IN Sify Limited 4 - AS33783 43711 0.7% 319.1 -- EEPAD 5 - AS26829 42770 0.7% 42770.0 -- YKK-USA - YKK USA,INC 6 - AS123934014 0.6% 8.8 -- SPRINTLINK - Sprint 7 - AS815133836 0.6% 28.1 -- Uninet S.A. de C.V. 8 - AS845233410 0.6% 27.6 -- TEDATA TEDATA 9 - AS480233327 0.6% 64.1 -- ASN-IINET iiNet Limited 10 - AS982933168 0.6% 40.9 -- BSNL-NIB National Internet Backbone 11 - AS21332 32373 0.6%1245.1 -- NTC-AS New Telephone Company 12 - AS17974 32223 0.6% 72.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 13 - AS432325748 0.4% 6.3 -- TWTC - Time Warner Telecom, Inc. 14 - AS580325330 0.4% 145.6 -- DDN-ASNBLK - DoD Network Information Center 15 - AS19334 21980 0.4% 21980.0 -- SPORTLINE-DBC - SPORTLINE 16 - AS701820912 0.3% 13.9 -- ATT-INTERNET4 - ATT WorldNet Services 17 - AS461820640 0.3% 338.4 -- INET-TH-AS Internet Thailand Company Limited 18 - AS614020320 0.3% 26.8 -- IMPSAT-USA - ImpSat USA, Inc. 19 - AS17443 20189 0.3% 448.6 -- ESTELCOM-AP International Internet gateway , India 20 - AS462120090 0.3% 130.5 -- UNSPECIFIED UNINET-TH TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS26829 42770 0.7% 42770.0 -- YKK-USA - YKK USA,INC 2 - AS19334 21980 0.4% 21980.0 -- SPORTLINE-DBC - SPORTLINE 3 - AS13495 15547 0.3% 15547.0 -- NTT do Brasil Telecomunicaoes Ltda 4 - AS21291 12845 0.2% 12845.0 -- OMEGABANK 8 Dragatsaniou str 5 - AS32398 17643 0.3%8821.5 -- REALNET-ASN-1 6 - AS174877464 0.1%7464.0 -- ICBCASIA-AP Industrial and Commercial Bank 7 - AS309295867 0.1%5867.0 -- HUTCB Hidrotechnical Faculty - Technical University 8 - AS414825789 0.1%5789.0 -- CLUEAG-AS Clue AG IT Solutions 9 - AS190175527 0.1%5527.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 10 - AS292255433 0.1%5433.0 -- TAIF-TELCOM-AS JSC TAIF-TELCOM 11 - AS797414173 0.2%3543.2 -- Instituto Mexicano del Petroleo 12 - AS4184 6895 0.1%3447.5 -- STORTEK-WHQ - Storage Technology Corporation 13 - AS322073247 0.1%3247.0 -- 14 - AS145765802 0.1%2901.0 -- RHNL-NET - Righthosting.com 15 - AS289775362 0.1%2681.0 -- UN-UNLB United Nations Logistics Base Brindisi, Italy 16 - AS286462620 0.0%2620.0 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 17 - AS409812413 0.0%2413.0 -- UNIVCG University of Montenegro 18 - AS324552257 0.0%2257.0 -- FNIS-HAWAII - FNIS 19 - AS433822244 0.0%2244.0 -- IFOLOR-FIKA-AS IFI Oy 20 - AS38206 12657 0.2%2109.5 -- ESTATIONPRIM-AS-AP eStation Pty Ltd Australia Primary AS Hosting Service Provider TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 203.101.87.0/24 61874 1.0% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - 12.108.254.0/24 42770 0.7% AS26829 -- YKK-USA - YKK USA,INC 3 - 80.243.64.0/2031379 0.5% AS21332 -- NTC-AS New Telephone Company 4 - 202.140.63.0/24 30567 0.5% AS17443 -- ESTELCOM-AP International Internet gateway , India AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 5 - 203.55.229.160/2 27960 0.5% AS4802 -- ASN-IINET iiNet Limited 6 - 63.169.11.0/2421980 0.3% AS19334 -- SPORTLINE-DBC - SPORTLINE 7 - 124.7.35.0/24 19021 0.3% AS9583 -- SIFY-AS-IN Sify Limited 8 - 41.204.0.0/24 17592 0.3% AS32398 -- REALNET-ASN-1 9 - 203.63.26.0/2416806 0.3% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 10 - 89.4.130.0/24 16712 0.3% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 11 - 89.4.131.0/24 16577 0.3% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 12 - 200.194.64.0/19 15547 0.2% AS13495 -- NTT do Brasil Telecomunicaoes Ltda 13 - 124.7.244.0/2415139 0.2% AS9583 -- SIFY-AS-IN Sify Limited 14 - 89.4.128.0/24 15016 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 15 - 89.4.129.0/24
The Cidr Report
This report has been generated at Fri Mar 7 21:14:14 2008 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
29-02-08253399 160360
01-03-08253645 161077
02-03-08253907 161337
03-03-08253940 161721
04-03-08254078 162873
05-03-08254441 163349
06-03-08254636 164080
07-03-08255204 164685
AS Summary
27768 Number of ASes in routing system
11637 Number of ASes announcing only one prefix
1599 Largest number of prefixes announced by an AS
AS4755 : VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System
88768000 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 07Mar08 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 255498 1647189078035.5% All ASes
AS9498 1194 121 107389.9% BBIL-AP BHARTI BT INTERNET
LTD.
AS4755 1599 628 97160.7% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS4323 1383 436 94768.5% TWTC - Time Warner Telecom,
Inc.
AS18566 1043 242 80176.8% COVAD - Covad Communications
Co.
AS11492 1219 452 76762.9% CABLEONE - CABLE ONE
AS8151 1191 487 70459.1% Uninet S.A. de C.V.
AS19262 886 205 68176.9% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS17488 1016 337 67966.8% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS6478 933 362 57161.2% ATT-INTERNET3 - ATT WorldNet
Services
AS18101 710 151 55978.7% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS2386 1393 866 52737.8% INS-AS - ATT Data
Communications Services
AS22773 886 359 52759.5% CCINET-2 - Cox Communications
Inc.
AS4134 869 393 47654.8% CHINANET-BACKBONE
No.31,Jin-rong Street
AS4812 562 104 45881.5% CHINANET-SH-AP China Telecom
(Group)
AS19916 557 101 45681.9% ASTRUM-0001 - OLM LLC
AS6197 996 549 44744.9% BATI-ATL - BellSouth Network
Solutions, Inc
AS17676 509 67 44286.8% GIGAINFRA BB TECHNOLOGY Corp.
AS855555 115 44079.3% CANET-ASN-4 - Bell Aliant
AS7018 1457 1026 43129.6% ATT-INTERNET4 - ATT WorldNet
Services
AS4766 868 443 42549.0% KIXS-AS-KR Korea Telecom
AS3356 854 441 41348.4% LEVEL3 Level 3 Communications
AS6389 889 490 39944.9% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS9443 452 77 37583.0% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS7545 505 133 37273.7% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS4808 516 151 36570.7% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS6140 611 247 36459.6% IMPSAT-USA - ImpSat USA, Inc.
AS5668 675 313 36253.6% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS16814 426 70 35683.6% NSS S.A.
AS4668 528 175 35366.9% LGNET-AS-KR LG CNS
AS1785 608 275 33354.8% AS-PAETEC-NET - PaeTec
Communications, Inc.
Total 25890 98161607462.1% Top 30 total
Possible Bogus Routes
14.0.0.0/8 AS27044 DDN-ASNBLK1 - DoD
Data Centre Migration
Looking for a consultant or someone that could help a company I am working with migrate 15 racks of servers from Canada to US. Not all will be coming, but we will be re-purchasing some equipment to create a second data centre. Anyone interested or knows someone please contact me offlist. -Dennis
Re: 3rd party network monitoring
One app I like a lot is Ping Plotter, but it only runs on Windows, so it isn't good for remote monitoring. We do use it for some things, however. I like the detailed traceroute / latency visualization it has. It also has a hard time with a lot (100+) nodes being monitored. SmokePing works well, but lacks detail in the form of traceroute. Jeroen Massar wrote: John A. Kilpatrick wrote: On Wed, 5 Mar 2008, Tom Sands wrote: When we did get a hold of someone, they mentioned they could support simple ICMP requests. To them simple means it's just a ping check. They won't montior/graph/care about latency. I was pondering creating a smoke ping collective. Get a bunch of guys to agree to run smokeping and monitor each other. That's a great tool for visualizing changes in latency and works just as well with ICMP as with HTTP. There is this really awesome project from RIPE (like usual ;) Please check, and start using RIPE TTM: http://www.ripe.net/ttm/ See the site for presentations, tools, info, etc etc etc etc... Enjoy ;) Greets, Jeroen
Re: 3rd party network monitoring
My bad, you might be able to do it with PingPlotter using remote proxies that are linux. I can see using the Vixie personal colo list to find cheap vm offerings in various locations. Other option, a few could get together and share some resources to get the proxies distributed. http://www.pingplotter.com/manual/pro/remote_trace.html Jeroen Massar wrote: John A. Kilpatrick wrote: On Wed, 5 Mar 2008, Tom Sands wrote: When we did get a hold of someone, they mentioned they could support simple ICMP requests. To them simple means it's just a ping check. They won't montior/graph/care about latency. I was pondering creating a smoke ping collective. Get a bunch of guys to agree to run smokeping and monitor each other. That's a great tool for visualizing changes in latency and works just as well with ICMP as with HTTP. There is this really awesome project from RIPE (like usual ;) Please check, and start using RIPE TTM: http://www.ripe.net/ttm/ See the site for presentations, tools, info, etc etc etc etc... Enjoy ;) Greets, Jeroen
Re: 3rd party network monitoring
Jason LeBlanc wrote: My bad, you might be able to do it with PingPlotter using remote proxies that are linux. I can see using the Vixie personal colo list to find cheap vm offerings in various locations. Other option, a few could get together and share some resources to get the proxies distributed. Did you actually *check* the URL I passed in? TTM does quite a bit more and is already distributed around the world and available to ISP's. Again: There is this really awesome project from RIPE (like usual ;) Please check, and start using RIPE TTM: http://www.ripe.net/ttm/ See the site for presentations, tools, info, etc etc etc etc... Greets, jeroen signature.asc Description: OpenPGP digital signature
Re: 3rd party network monitoring
I did look at it, it still lacks a few things, but it does cover most. It would be nice if you added some screenshots or demo pages as to what the reporting looks like. I had to dig around and find a paper on the slammer worm to see what the output looks like. Jeroen Massar wrote: Jason LeBlanc wrote: My bad, you might be able to do it with PingPlotter using remote proxies that are linux. I can see using the Vixie personal colo list to find cheap vm offerings in various locations. Other option, a few could get together and share some resources to get the proxies distributed. Did you actually *check* the URL I passed in? TTM does quite a bit more and is already distributed around the world and available to ISP's. Again: There is this really awesome project from RIPE (like usual ;) Please check, and start using RIPE TTM: http://www.ripe.net/ttm/ See the site for presentations, tools, info, etc etc etc etc... Greets, jeroen
Re: 3rd party network monitoring
Jason LeBlanc wrote: I did look at it, it still lacks a few things, but it does cover most. It would be nice if you added some screenshots or demo pages as to what the reporting looks like. I had to dig around and find a paper on the slammer worm to see what the output looks like. Contact RIPE NCC for that, if you would have read it, you would have found that it is their project. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Rogue traffic commonly perceived as noise (was: Scan traffic from 121.8.0.0/16)
Yeah, much of it is noise. However there is a a lot of coordination to much of what I'm seeing. Many of the scans stop at hosts with accessible SSH daemons and pound on them for minutes to hours. Others are more subtle. I'll see one host scan our ranges and pick out the IPs running SSH. Then, a short time later, those specific hosts are directly targeted from a different compromised host implying that there is communication on the back-end about IPs w/ SSH daemons. I tested the theory by disabling SSH on a few of the hosts picked up in earlier mass scans. The targeted attacks are still aimed at those hosts learned in the earlier scan even though their SSH daemons we effectively offline. Some scans are so slow they're barely noticeable (as was reports on the SANS ISC site recently). Even though much of this is simply noise and typical life on the Internet, I have to wonder how much of this noise is actual reconnaissance against SPs and their customers. A certain large SE Asian country's military is widely reported to be performing recon and attacks against IP resources around the globe. How much of what people believe is noise is actually malicious traffic or a prelude to some future event? Frankly the scans on my network have been significantly reduced by being a little more proactive with my monitoring. I've found that network generating SSH scans are also being used for telnet, MS-SQL and SMTP scans. Unfortunately the processes I'm utilizing are very labor intensive and I can't keep doing this forever. I would love to find a tool that could help me automate some of this process and hopefully react faster than I can. While typing this 69.13.181.99 just scanned one of our /19s. The flood of packets was so fast I wouldn't have been able to null route it even if I'd been actively watching the flows. The only way I could have slowed it down would have been to rate-limit SYNs. That leads to a good question for NANOG at large which I'll post separately. Justin Martin Hannigan wrote: Scans are really a dime a dozen and noise that buries good data on real problems. Be careful! On 3/6/08, Justin Shore [EMAIL PROTECTED] wrote: Rich Sena wrote: Anyone seeing anything similar - trying to determine if this is spoofed etc... I haven't picked up any SSH or telnet scans from that network. That's what I'm looking for at the moment. The amount of scans we're getting are quite impressive at times. I wish there was an easy way to automate the care and feeding of my RTBH with this data (and some sanity checks). Justin
Customer-facing ACLs
This question will probably get lost in the Friday afternoon lull but we'll give it a try anyway. What kind of customer-facing filtering do you do (ingress and egress)? This of course is dependent on the type of customer, so lets assume we're talking about an average residential customer. Do you block SYNs destined to your customers? Do you rate-limit SYNs destined for your customers? SYNs on privileged ports? Do you block any customer-facing egress traffic at all? What about ingress? SMTP, NetBIOS, MS-SQL, common proxy ports (3128, 6588)? What ICMP types do you allow or disallow? I'm assuming everyone uses uRPF at all their edges already so that eliminates the need for specific ACEs with ingress/egress network verification checks. Do you filter anything destined to your network infrastructure on your customer-facing edges? Does anyone filter traffic destined to the PE side of a PE-CE link from the outside world? For those of you with cable networks, what all do you block with the CM? We're considering blocking NetBIOS and DHCP server traffic (DHCP server packets are already blocked at the CMTS but this would keep that junk off our infrastructure). For SMTP we permit access to our SMTP servers on tcp/25 to all our broadband users. We also permit our customers with static IPs (residential and business) to send SMTP without restrictions. After those permits we explicitly block tcp/25. This has worked fairly well for us. It sure makes it easy to find infected PCs with spambots. We don't touch tcp/587. For ICMP we permit echo, replies, packet-too-big, and time-exceeded. Everything else gets dropped. Frags are explicitly dropped before any permits. We also block common proxy ports to and from the customers (the to includes ports not always used for proxies). This has been very effective in catching a number of bots that scanned for open Squid proxies or script kiddie junk that used WinGate with the default settings. Is there a BCP for customer-facing ACLs? Justin
Re: Customer-facing ACLs
On Fri, 7 Mar 2008, Justin Shore wrote: Do you block any customer-facing egress traffic at all? What about ingress? SMTP, NetBIOS, MS-SQL, common proxy ports (3128, 6588)? What ICMP types do you allow or disallow? In my previous life, I worked at a mid-sized ISP. A common practice for bridged DSL customers was to block outbound traffic to the various Netbios ports, along with a few other ports that were added at the time to keep Slammer and friends under control. We also deployed filters through RADIUS that covered much of the same ground for dialup and PPPoE DSL users and it worked reasonably well. I do recall weighing the merits of extending that to drop outbound SMTP to exerything except our mail farm, but it wasn't deployed because there was a geat deal a fear of customer backlash and that it would drive more calls into the call center. jms
Re: Customer-facing ACLs
On Fri, 07 Mar 2008 13:55:05 CST, Justin Shore said: I'm assuming everyone uses uRPF at all their edges already so that eliminates the need for specific ACEs with ingress/egress network verification checks. You're new here, aren't you? :) pgpck6mspgZyp.pgp Description: PGP signature
Re: Customer-facing ACLs
[EMAIL PROTECTED] wrote: On Fri, 07 Mar 2008 13:55:05 CST, Justin Shore said: I'm assuming everyone uses uRPF at all their edges already so that eliminates the need for specific ACEs with ingress/egress network verification checks. You're new here, aren't you? :) Hopefully optimistic. Don't bum me out going into a weekend... :-) From the looks of my ingress BOGON ACLs on my borders (yes, I'm using ACLs and not null routes for a reason) I'd most people not reading NANOG (and maybe even some of them!) are not doing any ingress filtering on their customer source IPs. Sad Justin
Re: Customer-facing ACLs
I would *love* to be able to run uRPF on all of our edge devices, but we use Cisco ME3400s, 3550s, 3560s and they don't support it. :-( [EMAIL PROTECTED] wrote: On Fri, 07 Mar 2008 13:55:05 CST, Justin Shore said: I'm assuming everyone uses uRPF at all their edges already so that eliminates the need for specific ACEs with ingress/egress network verification checks. You're new here, aren't you? :)
Re: Customer-facing ACLs
On Fri, Mar 07, 2008 at 01:55:05PM -0600, Justin Shore wrote: What kind of customer-facing filtering do you do (ingress and egress)? This of course is dependent on the type of customer, so lets assume we're talking about an average residential customer. ... As part of a recent measurement project, we estimate the prevalence of ingress and egress blocking (though under the guise of neutrality). For customer facing filters, we leverage protocols which provide port-specific redirects, e.g. HTTP, Gnutella, etc. For traffic toward customers, we use port-specific tcptraceroutes. Some published data for the curious: http://ana.csail.mit.edu/rsp/ Reader's digest summary: NetBIOS ports (and the innocent profile service) 135-139 are among the most frequently blocked, along with SMTP, POP3 and filters that have stuck around due to various worms such as MS-SQL. That said, around 94% of the 16bit port space was unblocked by any network. Curious to other's answer to this high-level question -- and the more mundane question of filter maintenance. rob
Re: Customer-facing ACLs
Justin M. Streiner wrote: I do recall weighing the merits of extending that to drop outbound SMTP to exerything except our mail farm, but it wasn't deployed because there was a geat deal a fear of customer backlash and that it would drive more calls into the call center. This seems to be very common practice these days for larger ISPs/dialup aggregators using the appropriate RADIUS attributes on supported access servers. We generally restrict outbound SMTP on our dial-up users so they may only reach our hosts (or the mail hosts of our wholesale customers). Our DSL subscribers, both dynamic and static, are currently unfiltered -- but we're very quick to react to abuse incidents and apply filters when necessary until the user cleans up their network. I'm currently on the fence with regards to filtering SMTP for all of our dynamic DSL folks. It'd be nice to prevent abuse before it happens, but it's a matter of finding the time to integrate the filtering into our wholesale backend and making sure there aren't any unforeseen issues. -- Kameron
RE: Customer-facing ACLs
We also use ingress bogon ACLs at our borders. -- Tim Sanderson, network administrator [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Shore Sent: Friday, March 07, 2008 3:20 PM To: [EMAIL PROTECTED] Cc: NANOG Subject: Re: Customer-facing ACLs [EMAIL PROTECTED] wrote: On Fri, 07 Mar 2008 13:55:05 CST, Justin Shore said: I'm assuming everyone uses uRPF at all their edges already so that eliminates the need for specific ACEs with ingress/egress network verification checks. You're new here, aren't you? :) Hopefully optimistic. Don't bum me out going into a weekend... :-) From the looks of my ingress BOGON ACLs on my borders (yes, I'm using ACLs and not null routes for a reason) I'd most people not reading NANOG (and maybe even some of them!) are not doing any ingress filtering on their customer source IPs. Sad Justin
Re: Customer-facing ACLs
On Mar 7, 2008, at 12:55 PM, Justin Shore wrote: This question will probably get lost in the Friday afternoon lull but we'll give it a try anyway. What kind of customer-facing filtering do you do (ingress and egress)? This of course is dependent on the type of customer, so lets assume we're talking about an average residential customer. We did ask some of these questions in the latest Infrastructure Security Survey, available here: http://www.arbornetworks.com/report Or here if you'd prefer not to register: http://www.tcb.net/wisr_2007_v3.pdf We're in the process of putting the next round of questions together, so if there are things you'd like added please let us know. -danny
Re: Customer-facing ACLs
--- What kind of customer-facing filtering do you do (ingress and egress)? This of course is dependent on the type of customer, so lets assume we're talking about an average residential customer. --- From a port-blocking point of view, some companies give access to the entire internet (good and bad) to their customers. Mine are mostly residential. scott fire + gasoline = religious argument on this issue that we've had *many* times in the past... ;-)
RE: Customer-facing ACLs
Same concerns here. Glad to know we're not alone. I think a transition to blocking outbound SMTP (except for one's own e-mail servers) would benefit from an education campaign, but perhaps the pain level is small enough that it can implemented without. One could start doing a subnet block a day to keep the helpdesk people sane, and then apply a global block at the edge once done to catch any subnets that one might have missed. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kameron Gasso Sent: Friday, March 07, 2008 2:44 PM To: Justin M. Streiner Cc: NANOG Subject: Re: Customer-facing ACLs Justin M. Streiner wrote: I do recall weighing the merits of extending that to drop outbound SMTP to exerything except our mail farm, but it wasn't deployed because there was a geat deal a fear of customer backlash and that it would drive more calls into the call center. This seems to be very common practice these days for larger ISPs/dialup aggregators using the appropriate RADIUS attributes on supported access servers. We generally restrict outbound SMTP on our dial-up users so they may only reach our hosts (or the mail hosts of our wholesale customers). Our DSL subscribers, both dynamic and static, are currently unfiltered -- but we're very quick to react to abuse incidents and apply filters when necessary until the user cleans up their network. I'm currently on the fence with regards to filtering SMTP for all of our dynamic DSL folks. It'd be nice to prevent abuse before it happens, but it's a matter of finding the time to integrate the filtering into our wholesale backend and making sure there aren't any unforeseen issues. -- Kameron
Re: Customer-facing ACLs
Scott Weeks wrote: fire + gasoline = religious argument on this issue that we've had *many* times in the past... ;-) I wore my flame-retardent tidy whiteys today though so I'm prepared. :-) I can understand the problem from both camps. As a tech-savvy user I don't want my provider to filter my Internet (I pay for both halves!). However having spent more time that I care to admit doing customer support and as a SP engineer I recognize the need to protect the masses who can't (or can't be bothered to) do it for themselves. SPs are really damned if we do and damned if we don't. Frankly I would rather do something than nothing. My overhead will increase in all categories if I do nothing. Infected hosts consume a significant portion of my resources. Tackling the problem reduces my overall support costs, increases 99% of my customers' overall satisfaction with our prices and services, but increases my labor costs and will spurn the ire of the 1% of my users who are tech-savvy enough to want/need unfiltered Internet access (or even understand the full implications of it, beyond the they're filtering something that was sent to me! limited thought process). To me there is no question of whether or not you filter traffic for residential broadband customers. The only thing beyond that is whether you as a SP also offer unfiltered packages. I personally thought the old SpeakEasy model was a nice approach. The unfiltered SysAdmin package was the perfect solution in my opinion. With my userbase I can think of only a tiny fraction of the users who would need such an offering. This would provide an acceptable solution for that very small percentage of users that need this kind of access. The other 99% of the users reap the benefits of our filtering. Problem solved IMHO. So that only leaves the question of what ports to block or rate-limit. Minimizing FPs is important. I think one could probably block 90% of the common crap without too much overhead. The remaining 10% would likely require too much labor to be worthwhile unless you were a sizable entity and could justify you RD by the sheer mass of your userbase. Justin
Re: Customer-facing ACLs
To me there is no question of whether or not you filter traffic for residential broadband customers. SBC in my area (Dallas) went from wide open to outbound 25 blocked by default/opened on request. I think doing the same thing with port 22 would hardly be an undue burden on users, and would help keep botnets in check. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Re: Customer-facing ACLs
--- [EMAIL PROTECTED] wrote: To me there is no question of whether or not you filter traffic for residential broadband customers. SBC in my area (Dallas) went from wide open to outbound 25 blocked by default/opened on request. I think doing the same thing with port 22 would hardly be an undue burden on users, and would help keep botnets in check. Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! scott
RE: Customer-facing ACLs
That's the problem isn't it? Who decides what can and cant go through. I think the tier approach is better, a basic user account where everything is blocked and a Sysadmin type account where everything is open. If the price is different enough then only people who are going to use those extra ports will actually pay for it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Weeks Sent: Friday, March 07, 2008 5:57 PM To: nanog@merit.edu Subject: Re: Customer-facing ACLs --- [EMAIL PROTECTED] wrote: To me there is no question of whether or not you filter traffic for residential broadband customers. SBC in my area (Dallas) went from wide open to outbound 25 blocked by default/opened on request. I think doing the same thing with port 22 would hardly be an undue burden on users, and would help keep botnets in check. Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! scott CONFIDENTIALITY AND SECURITY NOTICE The contents of this message and any attachments may be confidential and proprietary and also may be covered by the Electronic Communications Privacy Act. This message is not intended to be used by, and should not be relied upon in any way by, any third party. If you are not an intended recipient, please inform the sender of the transmission error and delete this message immediately without reading, disseminating, distributing or copying the contents. Citadel makes no assurances that this e-mail and any attachments are free of viruses and other harmful code.
Re: Customer-facing ACLs
Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! Do bots try brute force attacks on Telnet and FTP? All I see at my firewall are SSH attacks and spam. But sure, if there's a lot of Telnet abuse block 23 too; I think it's used about as rarely by normal customers as SSH is. And I'm amazed how often slippery slope arguments are deployed to oppose any sort of change at all. What percentage of consumer broadband users do you think use SSH to connect to remote servers? 1%? 0.1%? 0.01%? It seems intuitively obvious that the number of people who will call the help desk to unblock their SSH (which should be a ~2 minute call anyway, if not a self-service Web page with captcha) would be an order of magnitude less than the number of remote network users who WON'T be calling/emailing your abuse desk to complain about bots on your network hammering their servers. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
RE: Customer-facing ACLs
--- [EMAIL PROTECTED] wrote: That's the problem isn't it? Who decides what can and cant go through. I think the tier approach is better, a basic user account where everything is blocked and a Sysadmin type account where everything is open. If the price is different enough then only people who are going to use those extra ports will actually pay for it. We need to take this off-line. All long timers are groaning, rolling their eyes and putting this in their kill file. Try convincing your product managers to create a new product just to appease 'sysadmin types'. scott
RE: Customer-facing ACLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Scott Weeks [EMAIL PROTECTED] wrote: We need to take this off-line. All long timers are groaning, rolling their eyes and putting this in their kill file. Try convincing your product managers to create a new product just to appease 'sysadmin types'. Or perhaps engage the discussion on a security-related mailing list. A couple of suggestions: The DShield list: http://lists.dshield.org/mailman/listinfo/list Funsec: https://linuxbox.org/cgi-bin/mailman/listinfo/funsec - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFH0fhsq1pz9mNUZTMRAkIxAKDs7DqstE6bDyNmAbRkqrCW78pAtwCdH1hm gKrRg7ZAkEat2zx7XzRG+Nk= =SRGz -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/
Re: Customer-facing ACLs
Scott Weeks wrote: We need to take this off-line. All long timers are groaning, rolling their eyes and putting this in their kill file. Are the long-timers groaning and ignoring this thread? I certainly hope not. It's threads like these that need the benefit of their experience the most. Perhaps the long-timers could recommend a better destination for queries like these because I have more questions I want to ask (my next being about walled gardens). If they're tired of answering the same threads over and over again, then the query must be common enough to warrant a BCP or at the very least a couple documents in a knowledgebase somewhere. Perhaps my Google-fu isn't what it used to be but I couldn't manage to find any relevant docs online; not even a NANOG presentation. Try convincing your product managers to create a new product just to appease 'sysadmin types'. We're not in the business of alienating any customers. If we can create a bundle that meets a group of potential customers' needs we will. It's just another paragraph on the sales literature that we give our CSRs and a little more work that I'll have to do in configuration. I'm planning on rolling out SOHO and Gamer packages this year. Adding a SysAdmin package wouldn't be much additional work. I predict the adoption rate to be the highest with the Gamer package, followed by the SOHO package and finally the SysAdmin package. I hope this thread isn't destined for an untimely death. I've received a number of off-list queries for summary information because those individuals are also interested in customer-facing ACLs. The information I have to summarize at this point is brief and incomplete. Justin
Re: Customer-facing ACLs
On Fri, 7 Mar 2008, Dave Pooser wrote: Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! Do bots try brute force attacks on Telnet and FTP? All I see at my firewall are SSH attacks and spam. But sure, if there's a lot of Telnet abuse block 23 too; I think it's used about as rarely by normal customers as SSH is. And I'm amazed how often slippery slope arguments are deployed to oppose any sort of change at all. What percentage of consumer broadband users do you think use SSH to connect to remote servers? 1%? 0.1%? 0.01%? It seems intuitively obvious that the number of people who will call the help desk to unblock their SSH (which should be a ~2 minute call anyway, if not a self-service Web page with captcha) would be an order of magnitude less than the number of remote network users who WON'T be calling/emailing your abuse desk to complain about bots on your network hammering their servers. Just straight up blocking outbound ports (with the debatable exception of port 25) seems heavy handed and too slanted toward admin convenience over customer satisfaction. It's a slippery slope because unlike with spam, people who are affected by brute force attacks have some degree of complicity through either negligance or laziness. Once you decide it's your job to protect other people's networks from their own stupidity, you may as well do full blown deep packet inspection and look for customers who are using your network to download kiddie porn...step by step you get closer to losing safe harbor, or at least having to pay a lawyer to convince otherwise. Perhaps a more thoughtful solution would work, but would take a bit of engineering. Ideally you would only block a certain class of brute-forceable ports once you cross some threshold amount of brief TCP sessions in a given period. I would suspect an extremely low false positive rate of blocking the ports of a user who has had, say 100 brief telnet, ssh, ftp, pop, or imap sessions in 5 minutes. Perhaps instead of filtering just those ports, you instead do a captive portal where they forced to a webapp which presents them with the logs of their issues and the suggestion they may be compromised, along with locally reachable resources to assist in correcting the issue. But just in case, if they feel it was an accidental situation (a perl script gone mad, say), they could merely click a button to open them right back up. However, three strikes and you're out until an admin reviews the case and considers the feedback (we run a cyber cafe, sometimes people come in with messed up laptops) and implements a whitelisting. Remember, YOUR customers are what matter. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Re: Customer-facing ACLs
On Fri, Mar 07, 2008, Justin Shore wrote: Scott Weeks wrote: We need to take this off-line. All long timers are groaning, rolling their eyes and putting this in their kill file. Are the long-timers groaning and ignoring this thread? I certainly hope not. It's threads like these that need the benefit of their experience the most. Perhaps the long-timers could recommend a better destination for queries like these because I have more questions I want to ask (my next being about walled gardens). If they're tired of answering the same threads over and over again, then the query must be common enough to warrant a BCP or at the very least a couple documents in a knowledgebase somewhere. Perhaps my Google-fu isn't what it used to be but I couldn't manage to find any relevant docs online; not even a NANOG presentation. *waves* hai, I'm not an old-timer, but I'm still peripherally involved in this. As another poster pointed out, the access-list (and shaping! heh) rules available via RADIUS Vendor AV extensions are very, very useful. The little ISP I poke from time to time makes extensive use of them. The accounting software has some rudimentary profile support, so there's various types of customers which get certain RADIUS attributes. This allows for smart, home, business, and adrian users. Each gets different ACLs and shaping rules. There's a walled garden subnet for clients who haven't paid their bills. I haven't yet sat down and figured out how to drop users into a VRF based on something in the RADIUS reply, as this'd make for some very useful VPN and walled garden implementations, but its certainly on my todo list. Right after figure out IPv6, which is next on my list. Those running larger Cisco bbagg setups aren't rolling the old-school RADIUS authentication; Cisco apparently have some better stuff available now. I can't comment on its effectiveness for accounting/authorisation/filtering. Try convincing your product managers to create a new product just to appease 'sysadmin types'. We're not in the business of alienating any customers. If we can create a bundle that meets a group of potential customers' needs we will. It's just another paragraph on the sales literature that we give our CSRs and a little more work that I'll have to do in configuration. I'm planning on rolling out SOHO and Gamer packages this year. Adding a SysAdmin package wouldn't be much additional work. I predict the adoption rate to be the highest with the Gamer package, followed by the SOHO package and finally the SysAdmin package. I hope this thread isn't destined for an untimely death. I've received a number of off-list queries for summary information because those individuals are also interested in customer-facing ACLs. The information I have to summarize at this point is brief and incomplete. I'll update the NANOG Wiki with whatever information pops up. Amusingly, a newish WISP out here in Western Australia seems to have not implemented this sort of stuff, and wireless clients on the same node can see other local customers. I think their CPE device is a bridge, and this is about as dangerous as it sounds. It would be nice to have a BCP or presentation covering the how's and why's for the newer entrants into ths market. (Although that said, why would you help them? In business, you may just want (some of) your competitors to fail. :) Adrian
Re: Customer-facing ACLs
Just straight up blocking outbound ports (with the debatable exception of port 25) seems heavy handed and too slanted toward admin convenience over customer satisfaction. It's a slippery slope because unlike with spam, people who are affected by brute force attacks have some degree of complicity through either negligance or laziness. Sure, and I could* make the argument that since I have great spam filtering inbound I don't have to care about outbound spam from my network because if you receive it it's because of your negligence/laziness. But I think that in the case of spam as in the case of brute force attacks it's still the network operator's obligation to be a good netizen providing doing so places no undue burden on his own customers or his own staff. Blocking port 25 outbound for dynamic users until they specifically request it be unblocked seems to me to meet the no undue burden test; so would port 22 and 23. Beyond that, I'd probably be hesitant until I either started getting a significant number of abuse reports about a certain flavor of traffic that I had reason to believe was used by only a tiny minority of my own users. *but won't, ever -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Re: Customer-facing ACLs
Blocking port 25 outbound for dynamic users until they specifically request it be unblocked seems to me to meet the no undue burden test; so would port 22 and 23. Beyond that, I'd probably be hesitant until I either started getting a significant number of abuse reports about a certain flavor of traffic that I had reason to believe was used by only a tiny minority of my own users. Sorry, I must've missed something. Port 25 outbound (excepting ISP SMTP server) seems entirely logical to me. Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a concern? I can only assume it's to stop clients exploited boxen being used to anonymise further telnet/ssh attempts - but have to admit this discussion is the first i've heard of it being done 'en masse'. It'd frustrate me if I jacked into a friends Internet in order to do some legitimate SSH based server administration, I imagine... Is this not 'reaching' or is there a genuine benefit in blocking these ports as well? Mark.
Re: Customer-facing ACLs
Dave Pooser wrote: To me there is no question of whether or not you filter traffic for residential broadband customers. SBC in my area (Dallas) went from wide open to outbound 25 blocked by default/opened on request. I think doing the same thing with port 22 would also people who do real work... hardly be an undue burden on users, and would help keep botnets in check. it would cause me to be a customer of a different service.
RE: Customer-facing ACLs
The last few spam incidents I measured an outflow of about 2 messages per second. Does anyone know how aggressive Telnet and SSH scanning is? Even if it was greater, it's my guess there are many more hosts spewing spam than there are running abusive telnet and SSH scans. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Foster Sent: Friday, March 07, 2008 10:02 PM To: Dave Pooser Cc: nanog@merit.edu Subject: Re: Customer-facing ACLs Blocking port 25 outbound for dynamic users until they specifically request it be unblocked seems to me to meet the no undue burden test; so would port 22 and 23. Beyond that, I'd probably be hesitant until I either started getting a significant number of abuse reports about a certain flavor of traffic that I had reason to believe was used by only a tiny minority of my own users. Sorry, I must've missed something. Port 25 outbound (excepting ISP SMTP server) seems entirely logical to me. Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a concern? I can only assume it's to stop clients exploited boxen being used to anonymise further telnet/ssh attempts - but have to admit this discussion is the first i've heard of it being done 'en masse'. It'd frustrate me if I jacked into a friends Internet in order to do some legitimate SSH based server administration, I imagine... Is this not 'reaching' or is there a genuine benefit in blocking these ports as well? Mark.
Re: Customer-facing ACLs
Frank Bulk wrote: The last few spam incidents I measured an outflow of about 2 messages per second. Does anyone know how aggressive Telnet and SSH scanning is? Even if it was greater, it's my guess there are many more hosts spewing spam than there are running abusive telnet and SSH scans. Judging by the hits on my firewall there's a fair amount of variation between the scanners that are doing a couple login attempts per hour, and the bot that's making thousands of login attempts with 4 or 5 connection attempts going at a time. We don't filter them till they hit a threshold. I don't even bother to log telnet attempts anymore so I can't say much about that. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Foster Sent: Friday, March 07, 2008 10:02 PM To: Dave Pooser Cc: nanog@merit.edu Subject: Re: Customer-facing ACLs Blocking port 25 outbound for dynamic users until they specifically request it be unblocked seems to me to meet the no undue burden test; so would port 22 and 23. Beyond that, I'd probably be hesitant until I either started getting a significant number of abuse reports about a certain flavor of traffic that I had reason to believe was used by only a tiny minority of my own users. Sorry, I must've missed something. Port 25 outbound (excepting ISP SMTP server) seems entirely logical to me. Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a concern? I can only assume it's to stop clients exploited boxen being used to anonymise further telnet/ssh attempts - but have to admit this discussion is the first i've heard of it being done 'en masse'. It'd frustrate me if I jacked into a friends Internet in order to do some legitimate SSH based server administration, I imagine... Is this not 'reaching' or is there a genuine benefit in blocking these ports as well? Mark.
Re: Customer-facing ACLs
Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a concern? I can only assume it's to stop clients exploited boxen being used to anonymise further telnet/ssh attempts - but have to admit this discussion is the first i've heard of it being done 'en masse'. On one test machine that I leave SSH unfirewalled on, I'll see 200-4000 SSH login attempts per day, trying to brute force it. Lets see, this morning in an eight-minute span from one IP in Aruba 100 attempts for root; other usernames attempted include admin, staff, sales, office, alias, stud (!), trash, guest, test, oracle, a few personal names, apache, svn, iraf, swsoft, gast, sirsi and nagios. And this is a relatively slow day. Telnet I wouldn't know about, but I'm told bots will try to force it as well. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Re: Customer-facing ACLs
On Sat, 8 Mar 2008, Dave Pooser wrote: Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a concern? I can only assume it's to stop clients exploited boxen being used to anonymise further telnet/ssh attempts - but have to admit this discussion is the first i've heard of it being done 'en masse'. On one test machine that I leave SSH unfirewalled on, I'll see 200-4000 SSH login attempts per day, trying to brute force it. Lets see, this morning in an eight-minute span from one IP in Aruba 100 attempts for root; other usernames attempted include admin, staff, sales, office, alias, stud (!), trash, guest, test, oracle, a few personal names, apache, svn, iraf, swsoft, gast, sirsi and nagios. And this is a relatively slow day. Telnet I wouldn't know about, but I'm told bots will try to force it as well. Oh, there's plenty of names in one of my server logs too... looks almost like they've gone through a name-choosing handbook. I can understand the logic of dropping the port, but theres some additional thought involved when looking at Port 22 - maybe i'm not well-read enough, but the bots I've seen that are doing SSH scans, etc, are not usually on Windows systems. I can figure them working on Linux, MacOS systems - but surely the vast majority of 'vulnerable' hosts are those running OS's coming from our favourite megacorp? Which typically don't come shipped with neither SSH server nor SSH client... ? To me, at least half the users likely to be running either Linux or Mac are going to be the same users who're going to request they be allowed outbound SSH is the blocking of outbound SSH considered to be sufficiently useful that we're advocating it these days? (Aren't we all just moving SSH to non-standard ports within our networks anyway?) ... Mark.
