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
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
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
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] 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
Valdis.Kletnieks@vt.edu 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
We also use ingress bogon ACLs at our borders. -- Tim Sanderson, network administrator tims@donet.com -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Justin Shore Sent: Friday, March 07, 2008 3:20 PM To: Valdis.Kletnieks@vt.edu Cc: NANOG Subject: Re: Customer-facing ACLs Valdis.Kletnieks@vt.edu 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
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. :-( Valdis.Kletnieks@vt.edu 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? :)
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
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
On Saturday 08 March 2008, 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.
We supply to mid-to-small ISP's mostly, and sizeable enterprise customers; so the degree to which we can filter is limited. That said, at the edge, we run uRPF on all customer-facing ports (loose or strict, depending on the deployment). In addition, on each edge router's core-facing uplinks, we run egress ACL's matching RFC 1918 and RFC 3330 (yes, with uRPF downstream to the customers, this might seem redundant, but we've actually seen some 'catches', so it appears to help us solidify our filtering implementation). In the core, we don't filter or run uRPF, for obvious reasons. On our border routers, we deploy ingress filters, again, cutting off RFC 1918 and RFC 3330. On peering routers (private peering and exchange points), we run uRPF on our peering interface (taking care to run loose mode in case private peers also peer at the public exchange point). Again, upstream ACL's are implemented on core-facing uplinks to "double-check". As you can tell, we don't filter protocols/ports/applications. We leave that to the customer, and insist on it. All the above goes for IPv6 as well, as appropriate. We are also quite picky about NLRI filtering (BGP), but that's beyond this scope :-). Hope this helps. Cheers, Mark.
I've attempted to summarise the replies I found useful in the Wiki: http://nanog.cluepon.net/index.php/MailTopics#Customer-Facing_ACLs My personal observations: * More information about what networks are doing would be nice! * More data points about probes/scans/etc would be nice! * Filtering technologies would be nice for ACLs - not shaping of things like BT/YT/etc - stuff like how to deploy per-customer ACLs on a variety of tech. I know I've used ACLs in Radius AV pairs in a SP environment for DSL aggregation; I've also used similar hackery in 802.1x for per-port ethernet ACLs in an Enterprise environment. Has anyone rolled out 802.1x style port authentication in a ethernet- edge scenario and included ACLs/shaping AV-pairs? Experience/Feedback would be great. Constructive comments appreciated. Adrian
Justin Shore wrote:
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.
ha. I only wish that was true. We do filter all customer ports for IPs we believe from them, but darn few other providers do. (as based on my conversations with many providers when tracking down attacks from their networks) That said, we filter nothing else.
Frags are explicitly dropped before any permits.
...? So you have no real, production sites?
On Tue, Mar 11, 2008 at 2:27 AM, Jo Rhett <jrhett@netconsonance.com> wrote:
Justin Shore wrote:
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.
ha. I only wish that was true.
We do filter all customer ports for IPs we believe from them, but darn few other providers do. (as based on my conversations with many providers when tracking down attacks from their networks)
That said, we filter nothing else.
Frags are explicitly dropped before any permits.
...? So you have no real, production sites?
actually... depending upon platform the frags probably get through (on a cisco) if they are associated with another ongoing session... Cisco acls believe that frags are 'ok' (even if you deny fragments in the acl) unless the frag can't be put together with an existing session. Juniper just drops all frags...
participants (13)
-
Adrian Chadd -
Christopher Morrow -
Dan Armstrong -
Danny McPherson -
Frank Bulk -
Jo Rhett -
Justin M. Streiner -
Justin Shore -
Kameron Gasso -
Mark Tinka -
Robert Beverly -
Tim Sanderson -
Valdis.Kletnieks＠vt.edu