Customer-facing ACLs

Mailman List Mirror (Read Only)
1

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

2

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

3

You're new here, aren't you? :slight_smile:

4

Hopefully optimistic. Don't bum me out going into a weekend... :slight_smile:

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

5

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. :frowning:

6

...

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

7

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

8

We also use ingress bogon ACLs at our borders.

9

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

10

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

11

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.

12

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

13

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?

14

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...