Mailing List Archive: NANOG: users

Customer-facing ACLs

1 2 3

View All

Index | Next | Previous | View Threaded

morrowc.lists at gmail

Mar 10, 2008, 7:33 PM

Post #51 of 69 (1803 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On Mon, Mar 10, 2008 at 7:58 PM, Ang Kah Yik <mailinglist [at] bangky> wrote:
>
> Hi Justin (and all others on-list)
>
> I understand your grounds for blocking outbound SMTP for your customers
> (especially those on dynamic IP connections).
> It probably will do good to block infected customers that are spewing
> spam all over the world.
>
> However, considering the number of mobile workers out there who send
> email via their laptops to corporate SMTP servers, won't blocking
> outbound SMTP affect them?
>

vpns fix this...

> Since these corporate types (I'm guessing here) are probably unaware of
> how to change their email client's SMTP configurations, chances are that
> blocking outbound SMTP will probably cause quite a lot of pain.
>

uunet dialup has blocked port25 in both directions since 2002...
little to no complaints. (well, they may have received complaints
since I left, but... thank John StClair for the work behind that
filtering actually.)

> After all, there are also those who frequently move from place to place
> so they're going to have to keep changing SMTP servers every time they
> go to a new place that's on a different ISP.
>

many config's actually just use WCCP to transparently redirect your
smtp to an authorized SMTP server as Andy Dills points out.

-Chris

justin at justinshore

Mar 10, 2008, 9:04 PM

Post #52 of 69 (1801 views)
Permalink

Re: Customer-facing ACLs [In reply to]

Ang Kah Yik wrote:
>
> However, considering the number of mobile workers out there who send
> email via their laptops to corporate SMTP servers, won't blocking
> outbound SMTP affect them?
>
> After all, there are also those who frequently move from place to place
> so they're going to have to keep changing SMTP servers every time they
> go to a new place that's on a different ISP.

Thanks for joining the discussion. Frankly I'd be surprised to find
many corps with an externally-accessible SMTP server that would accept
mail on tcp/25. The only way they'd do it is with SMTP AUTH which
(hopefully) implies the use of SMTP TLS as well. I know of very few
corps that actually do this. Most of the corps I can think of are
either running Exchange and utilizing RPC over HTTP, simply point their
users to their company's webmail server, or require that their users VPN
back to HQ to access their internal MTA. The sites that I can think of
with external user-accessible SMTP daemons are entities with highly
technical users. They utilize SMTP AUTH, TLS, and the Mail Submission
Port on tcp/587. I'm afraid they are in the minority though.

The MSP port is the best way to get around the blocks with decent MTAs.
Your local MTA's support for other non-standard mechanisms for
relaying mail from untrusted networks may also help with this problem
(RPC over HTTP). Other than that I don't think there's enough demand
for outgoing SMTP from the masses to warrant not blocking it.
Redirecting generally takes care of that anyway.

Thanks for the input though. All thoughts are welcome.
Justin

adrian at creative

Mar 10, 2008, 9:18 PM

Post #53 of 69 (1802 views)
Permalink

Re: Customer-facing ACLs [In reply to]

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

frnkblk at iname

Mar 10, 2008, 10:10 PM

Post #54 of 69 (1797 views)
Permalink

RE: Customer-facing ACLs [In reply to]

We have a two-dozen line long ACL applied to our CMTS and BRAS blocking
Windows and "virus" ports and have never had a complaint or a problem. We
do have a more sophisticated residential or large-biz customers ask, but
only once has our ACL been the source of a problem and it's only because the
OEM version of the software didn't implement communications the same way as
their branded version.

Frank

-----Original Message-----
From: owner-nanog [at] merit [mailto:owner-nanog [at] merit] On Behalf Of Sean
Donelan
Sent: Monday, March 10, 2008 2:30 PM
To: Scott Weeks
Cc: nanog [at] merit
Subject: Re: Customer-facing ACLs

On Mon, 10 Mar 2008, Scott Weeks wrote:
> The hard part is I now always take over networks that have been in
> operation a long time and enabling these policies can be very painful
> after the fact. Establishing them when the network is new is a
> different story.

Whatever you decide, whether you know what the policies are or not, there
are always have a set of default network policies.

The question is do you explain to you customers just as carefully what
your default policy doesn't do, as well as what it does. Do you take
just as much time to carefully explain the risks and what may break to
your customers of allowing that traffic as you would of not allowing that
traffic.

It seems to be very painful whatever decision is made.

frnkblk at iname

Mar 10, 2008, 10:15 PM

Post #55 of 69 (1803 views)
Permalink

RE: Customer-facing ACLs [In reply to]

Those using Google for SMTP can still use their ISP's SMTP servers for
outbound....

Frank

-----Original Message-----
From: owner-nanog [at] merit [mailto:owner-nanog [at] merit] On Behalf Of Ang
Kah Yik
Sent: Monday, March 10, 2008 7:40 PM
To: Andy Dills
Cc: nanog [at] merit
Subject: Re: Customer-facing ACLs

Hi Andy (and all who responded),

Thanks for the heads-up on the redirection on SMTP traffic. I've yet to
see an implementation of it but I agree that it's a possible solution.

As for the issue I raised previously, perhaps corporate users isn't a
good example but what about users of email services such as Gmail and
the like?
Some users do use the SMTP service instead of the web interface. But
redirection should do the trick.

And thanks to all who remind me about rfc 2476 - I'm not a mail admin so
I'm not familiar with it but I'll read up on it.

Andy Dills wrote:
> And wouldn't those corporate types require VPN to access the network?
>
> On top of that, most who "block" 25 don't block it but direct it to
> internal mail servers where it can be subjected to limits and filtering.
>
> Andy
>
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---
>
> For what it's worth, that's what port 587 was created for.

lists05 at equinephotoart

Mar 10, 2008, 11:25 PM

Post #56 of 69 (1810 views)
Permalink

Re: Customer-facing ACLs [In reply to]

Doesn't anyone RTFM before posting anymore?

http://mail.google.com/support/bin/answer.py?hl=en&answer=13287

# Configure your client to match the settings below:
Incoming Mail (POP3) Server - requires SSL: pop.gmail.com
Use SSL: Yes
Port: 995
Outgoing Mail (SMTP) Server - requires TLS: smtp.gmail.com (use
authentication)
Use Authentication: Yes
Use STARTTLS: Yes (some clients call this SSL)
Port: 465 or 587

There is no need to use smtp on port 25 with gmail. configure the
client according to gmail's instructions and use 465 or 587.

jc

Frank Bulk - iNAME wrote:
> Those using Google for SMTP can still use their ISP's SMTP servers for
> outbound....
>
> Frank
>
> -----Original Message-----
> From: owner-nanog [at] merit [mailto:owner-nanog [at] merit] On Behalf Of Ang
> Kah Yik
> Sent: Monday, March 10, 2008 7:40 PM
> To: Andy Dills
> Cc: nanog [at] merit
> Subject: Re: Customer-facing ACLs
>
>
> Hi Andy (and all who responded),
>
> Thanks for the heads-up on the redirection on SMTP traffic. I've yet to
> see an implementation of it but I agree that it's a possible solution.
>
> As for the issue I raised previously, perhaps corporate users isn't a
> good example but what about users of email services such as Gmail and
> the like?

jrhett at netconsonance

Mar 10, 2008, 11:27 PM

Post #57 of 69 (1810 views)
Permalink

Re: Customer-facing ACLs [In reply to]

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?

christopher.morrow at gmail

Mar 11, 2008, 11:41 AM

Post #58 of 69 (1804 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On Tue, Mar 11, 2008 at 2:27 AM, Jo Rhett <jrhett [at] netconsonance> 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...

surfer at mauigateway

Mar 11, 2008, 6:58 PM

Post #59 of 69 (1805 views)
Permalink

Re: Customer-facing ACLs [In reply to]

Apologies for the delay...

--- sean [at] donelan wrote:
On Mon, 10 Mar 2008, Scott Weeks wrote:

> The default policy is we allow eveything. It takes no explaining.

If you don't bother to explain to the same customers who you believe
couldn't figure out how to change the default settings, what the
risks and how to protect their computers on the Internet, is it any
wonder that normal user's have such a difficult time being safe on the
Internet?
------------------------------------------

Haven't you answered this in past posts on the subject? What are ISPs responsibilities and all...

-----------------------------
Implementing source address verification can take years, but if you
never start, you will never finish.

Implementing sanity checks for IP headers can take years, but if you
never start, you will never finish.

Implementing unsolicited/unwanted traffic controls can take years, but
if you never start, you will never finish.

Do you think caller-id/call-blocking/harrassing-call-trace were easy, or
rather they took years of hard work. Although the technology may change,
people seem to stay the same. And people seem to be adept at doing the
same stuff with new technology to other people.
-----------------------------

Yes, but each situation is different and you could not imagine how spread thin some netgeeks can get. Especially in a company that doesn't understand (yet) what it is we do. You could not imagine how thin it is here, but you REALLY learn a lot in a situation like this.

scott

surfer at mauigateway

Mar 11, 2008, 7:23 PM

Post #60 of 69 (1801 views)
Permalink

Re: Customer-facing ACLs [In reply to]

--- morrowc.lists [at] gmail wrote:

uunet dialup has blocked port25 in both directions since 2002...
little to no complaints. (well, they may have received complaints
since I left, but... thank John StClair for the work behind that
filtering actually.)
-----------------------------------------

I'd be curious as to how they implememted this. Prop up ALCs and deal with the complaints as they came? If, not how was the research done as to what was legitimate tcp25 and what wasn't. For how many customers? Residential, business or both? DHCP only or static too? etc...

scott

surfer at mauigateway

Mar 11, 2008, 7:34 PM

Post #61 of 69 (1806 views)
Permalink

RE: Customer-facing ACLs [In reply to]

sean at donelan

Mar 11, 2008, 7:57 PM

Post #62 of 69 (1797 views)
Permalink

RE: Customer-facing ACLs [In reply to]

> I'd like to ask the same question of you that I just did to Chris.
> How'd you implement that or has it been there since the network was new?

I would suggest a good resource is the MAAWG papers, and even though
you are stretched thin, consider attending a MAAWG meeting. MAAWG has
a lot of members that have already experienced the same situatations
as you, and may be able to help.

http://www.maawg.org/about/publishedDocuments

Obviously, I'm biased, but I like how SBC handled it :-) Not that it was
a problem free implementation.

frnkblk at iname

Mar 11, 2008, 7:57 PM

Post #63 of 69 (1797 views)
Permalink

RE: Customer-facing ACLs [In reply to]

Those ACLs were added when I came on board. Again, only one complaint in 3+
years.

And customers wonder why I shudder when they tell me that they plug in their
Win9x computers directly into their cable modem. I can't imagine how much
worse it would be if I didn't block the SMB ports.

Frank

-----Original Message-----
From: owner-nanog [at] merit [mailto:owner-nanog [at] merit] On Behalf Of
Scott Weeks
Sent: Tuesday, March 11, 2008 9:35 PM
To: nanog [at] merit
Subject: RE: Customer-facing ACLs

--- frnkblk [at] iname wrote: --------------------

We have a two-dozen line long ACL applied to our CMTS and BRAS blocking
Windows and "virus" ports and have never had a complaint or a problem. We
do have a more sophisticated residential or large-biz customers ask, but
----------------------------------------

I'd like to ask the same question of you that I just did to Chris. How'd
you implement that or has it been there since the network was new?

scott

surfer at mauigateway

Mar 12, 2008, 4:39 PM

Post #64 of 69 (1811 views)
Permalink

RE: Customer-facing ACLs [In reply to]

--- frnkblk [at] iname wrote: --------------------

We have a two-dozen line long ACL applied to our CMTS and BRAS blocking
Windows and "virus" ports and have never had a complaint or a problem. We
do have a more sophisticated residential or large-biz customers ask, but
----------------------------------------

I'd like to ask the same question of you that I just did to Chris. How'd
you implement that or has it been there since the network was new?

------ frnkblk [at] iname wrote: ------------
From: "Frank Bulk - iNAME" <frnkblk [at] iname>

Those ACLs were added when I came on board. Again, only one complaint in 3+
years.
--------------------------------------------

Do you mean they were already there when you arrived, or do you mean you just put in ACLs after arriving? No research into traffic? No contact to customers? No elaborating to the less technical folks in the company about what was going to happen? etc...

We have over 100k DSL folks and most're DHCP. I'd be afraid to do that without research into the traffic via "permit TCP NNN log" type ACLs and other methods.

I believe I will take Sean D's sugestion and read MAAWG's docs. Makes me wonder, though, if we took over the Hawaii part of VZ's network and it was completely open, does that mean the rest of their network is similarly open?

scott

frnkblk at iname

Mar 12, 2008, 7:22 PM

Post #65 of 69 (1796 views)
Permalink

RE: Customer-facing ACLs [In reply to]

Sorry, I should have been more clear. I added them a few months after I
came on board. The ports that are blocked are either Window's SMB/RPC ports
or the ones that (a long time ago) were used by worms. Correct, no research
into traffic or contact with customers. Although some may argue that
sharing one's files with their neighbor using Window's File and Print
sharing is a valid service, it's generally accepted that that residential
subscribers have no legitimate need to be communicating with those ports on
the internet and they are 100 times to 1 more likely to carry malicious
traffic than not. And as our history has shown, there's been close to zero
issues. Yes, perhaps customers just didn't bother to call in to complain or
that call wasn't escalated to me, but I think I could communicate a pretty
convincing argument if required.

Frank

-----Original Message-----
From: owner-nanog [at] merit [mailto:owner-nanog [at] merit] On Behalf Of
Scott Weeks
Sent: Wednesday, March 12, 2008 6:39 PM
To: nanog [at] merit
Subject: RE: Customer-facing ACLs

--- frnkblk [at] iname wrote: --------------------

We have a two-dozen line long ACL applied to our CMTS and BRAS blocking
Windows and "virus" ports and have never had a complaint or a problem. We
do have a more sophisticated residential or large-biz customers ask, but
----------------------------------------

I'd like to ask the same question of you that I just did to Chris. How'd
you implement that or has it been there since the network was new?

------ frnkblk [at] iname wrote: ------------
From: "Frank Bulk - iNAME" <frnkblk [at] iname>

Those ACLs were added when I came on board. Again, only one complaint in 3+
years.
--------------------------------------------

Do you mean they were already there when you arrived, or do you mean you
just put in ACLs after arriving? No research into traffic? No contact to
customers? No elaborating to the less technical folks in the company about
what was going to happen? etc...

We have over 100k DSL folks and most're DHCP. I'd be afraid to do that
without research into the traffic via "permit TCP NNN log" type ACLs and
other methods.

I believe I will take Sean D's sugestion and read MAAWG's docs. Makes me
wonder, though, if we took over the Hawaii part of VZ's network and it was
completely open, does that mean the rest of their network is similarly open?

scott

andy at nosignal

Mar 18, 2008, 12:58 PM

Post #66 of 69 (1775 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On 7 Mar 2008, at 23:57, Scott Weeks wrote:

> Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting
> slippery!

Oh, no, this one again.

*** The Internet Is Not The Web. ***

Could someone put that onto a t-shirt ?

If it becomes normal for home users to only have 80 and 443, then how
can I innovate and design something that needs a new protocol ? What
happens to the new voice and video services for example ?

On 11 Mar 2008, at 02:33, Christopher Morrow wrote:
> vpns fix this...

They stop fixing stuff when they stop working. If you start running
vpn services on tcp/80 (yuck, yuck, yuck), and naturally because it's
the only port open lots of other non http protocol stuff does too,
will filter-happy domestic providers start proxying the web instead of
just filtering the rest of the traffic ..?

Andy

tme at multicasttech

Mar 18, 2008, 1:27 PM

Post #67 of 69 (1771 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On Mar 18, 2008, at 3:58 PM, Andy Davidson wrote:

>
>
> On 7 Mar 2008, at 23:57, Scott Weeks wrote:
>
>> Might as well do TCP 20, 21 and 23, too. Woah, that slope's
>> getting slippery!
>
> Oh, no, this one again.
>
> *** The Internet Is Not The Web. ***
>
> Could someone put that onto a t-shirt ?
>
> If it becomes normal for home users to only have 80 and 443, then
> how can I innovate and design something that needs a new
> protocol ? What happens to the new voice and video services for
> example ?

The DOD has already been faced with this (I know of some AFB that
have instituted this policy).

The solution, of course, is to hire consultants (SIBR if possible) to
port everything to port 80 !

You can't say they don't have a plan.

Regards
Marshall

>
>
> On 11 Mar 2008, at 02:33, Christopher Morrow wrote:
>> vpns fix this...
>
> They stop fixing stuff when they stop working. If you start
> running vpn services on tcp/80 (yuck, yuck, yuck), and naturally
> because it's the only port open lots of other non http protocol
> stuff does too, will filter-happy domestic providers start proxying
> the web instead of just filtering the rest of the traffic ..?
>
>
> Andy

jlewis at lewis

Mar 18, 2008, 8:47 PM

Post #68 of 69 (1754 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On Tue, 18 Mar 2008, Marshall Eubanks wrote:

>> If it becomes normal for home users to only have 80 and 443, then how can I
>> innovate and design something that needs a new protocol ? What happens to
>> the new voice and video services for example ?
>
> The DOD has already been faced with this (I know of some AFB that have
> instituted this policy).
>
> The solution, of course, is to hire consultants (SIBR if possible) to port
> everything to port 80 !

That's been going on for years. Back when it was common for ISPs to run
squid servers and transparently proxy to them (probably around 2000), I
ran into a customer using some sort of aviation data in real time app
which used port 80 (and wasn't HTTP). I had to special case traffic to
that service's IP to get it not to hit squid. When I asked them why they
were running a non-HTTP protocol on 80/tcp, the answer was "that gets us
through most firewalls."

----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

adrian at creative

Mar 18, 2008, 9:46 PM

Post #69 of 69 (1762 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On Tue, Mar 18, 2008, Jon Lewis wrote:

> >The solution, of course, is to hire consultants (SIBR if possible) to port
> >everything to port 80 !
>
> That's been going on for years. Back when it was common for ISPs to run
> squid servers and transparently proxy to them (probably around 2000), I
> ran into a customer using some sort of aviation data in real time app
> which used port 80 (and wasn't HTTP). I had to special case traffic to
> that service's IP to get it not to hit squid. When I asked them why they
> were running a non-HTTP protocol on 80/tcp, the answer was "that gets us
> through most firewalls."

There's patches to Squid to make it silently transparently proxy stuff
that doesn't look like HTTP.

(I need to make it knob-able before I commit it, as some people -like- having
the "must be HTTP" implication of transparent interception.)

Adrian

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads