Mailing List Archive: NANOG: users

ISP port blocking practice

1 2 3 4 5 6

View All

Index | Next | Previous | View Threaded

zhiyunq at umich

Oct 22, 2009, 10:22 AM

Post #1 of 126 (1662 views)
Permalink

ISP port blocking practice

Hi all,

What is the common practice for enforcing port blocking policy (or
what is the common practice for you and your ISP)? More specifically,
when ISPs try to block certain outgoing port (port 25 for instance),
they could do two rules:
1). For any outgoing traffic, if the destination port is 25, then drop
the packets.
2). For any incoming traffic, if the source port is 25, then drop the
packets.

Note that either of the rule would be able to block outgoing port 25
traffic since each rule essentially represent one direction in a TCP
flow. Of course, they could apply both rules. However, based on our
measurement study, it looks like most of the ISPs are only using rule
1). Is there any particular reason why rule 1) instead of rule 2)? Or
maybe both?

Also, is it common that the rules are based on tcp flags (e.g. SYN,
SYN-ACK)? One would think block SYN packet is good enough.

Regards.
-Zhiyun

tony at lava

Oct 22, 2009, 10:32 AM

Post #2 of 126 (1619 views)
Permalink

Re: ISP port blocking practice [In reply to]

On Thu, 22 Oct 2009, Zhiyun Qian wrote:

> the common practice for you and your ISP)? More specifically, when ISPs try
> to block certain outgoing port (port 25 for instance), they could do two
> rules:
> 1). For any outgoing traffic, if the destination port is 25, then drop the
> packets.
> 2). For any incoming traffic, if the source port is 25, then drop the
> packets.
>
> Note that either of the rule would be able to block outgoing port 25 traffic
> since each rule essentially represent one direction in a TCP flow. Of course,
> they could apply both rules. However, based on our measurement study, it
> looks like most of the ISPs are only using rule 1). Is there any particular
> reason why rule 1) instead of rule 2)? Or maybe both?

Because rule 1 prevents the target server from having to respond to the
initial connection request in the first place thereby reducing load on the
server and reducing network traffic. Ie. both rules prevent the
connection but 1 stops it earlier.

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: tony [at] lava

Valdis.Kletnieks at vt

Oct 22, 2009, 10:33 AM

Post #3 of 126 (1618 views)
Permalink

Re: ISP port blocking practice [In reply to]

On Thu, 22 Oct 2009 13:22:17 EDT, Zhiyun Qian said:
> Hi all,
>
> What is the common practice for enforcing port blocking policy (or
> what is the common practice for you and your ISP)? More specifically,
> when ISPs try to block certain outgoing port (port 25 for instance),
> they could do two rules:
> 1). For any outgoing traffic, if the destination port is 25, then drop
> the packets.
> 2). For any incoming traffic, if the source port is 25, then drop the
> packets.
>
> Note that either of the rule would be able to block outgoing port 25
> traffic since each rule essentially represent one direction in a TCP
> flow. Of course, they could apply both rules. However, based on our
> measurement study, it looks like most of the ISPs are only using rule
> 1). Is there any particular reason why rule 1) instead of rule 2)? Or
> maybe both?

Note that some spammers use assymetric routing with forged packets - they
spew out a stream of crafted packets from a compromised machine, showing
a different source IP. The claimed source IP is also under the spammer's
control, and just basically has to catch the inbound SYN/ACK and forward
it to the spam-sender (and, if wanted, sink the other ACKs and forward the
SMTP replies from the server to the real sender). So you can have a big
sending pipe that doesn't get ingress-filtered(*) sending the spam, and do the
control from a throwaway that may have a small pipe.

(*) Of course it's not ingress-filtered - if somebody is selling a spammer
a big pipe for this, they can arrange to fail to filter. ;)

The upshot is, of course, that you want to do (1) because you never actually
see the (2) packets, they're going someplace else...

jfbeam at gmail

Oct 22, 2009, 2:37 PM

Post #4 of 126 (1611 views)
Permalink

Re: ISP port blocking practice [In reply to]

On Thu, 22 Oct 2009 13:22:17 -0400, Zhiyun Qian <zhiyunq [at] umich> wrote:
> 1). For any outgoing traffic, if the destination port is 25, then drop
> the packets.
> 2). For any incoming traffic, if the source port is 25, then drop the
> packets.

Inspecting outgoing traffic is generally easier to do as there's less of
it. (in a consumer context, which is the only place such filtering makes
any sense.)

--Ricky

justin at justinshore

Oct 22, 2009, 3:39 PM

Post #5 of 126 (1614 views)
Permalink

Re: ISP port blocking practice [In reply to]

Zhiyun Qian wrote:
> Hi all,
>
> What is the common practice for enforcing port blocking policy (or what
> is the common practice for you and your ISP)? More specifically, when
> ISPs try to block certain outgoing port (port 25 for instance), they
> could do two rules:
> 1). For any outgoing traffic, if the destination port is 25, then drop
> the packets.
> 2). For any incoming traffic, if the source port is 25, then drop the
> packets.

I block on both generally. I block inbound and outbound for residential
customers in dynamic pools. I block inbound only for residential with
statically-assigned IPs. That way a customer can request (and pay for)
a static IP and be able to get around out outbound SMTP block. Few
companies use the MSP port (tcp/587). I'm not sure why more don't make
the effort but most don't. To make up for that we allow static
residential customers to evade that filter with a static IP. We still
block inbound though. We also allow them to use our SMTP servers and
SmartHosts if they want with no requirements on source domains (like
some providers require, essentially requiring the customer to advertise
for you). The inbound block isn't really all that useful as you elude
to. However I use it more often than not to look for people scanning
out ranges for open relays. I use that data for feed my RTBH trigger
router and drop the spammer's traffic on the floor (or the poor,
unfortunate owner of the compromised PC that's been 0wned.

We block several other things too. Netbios traffic gets dropped both
ways. MS-SQL traffic gets dropped both ways (a few users have
complained about this but very few stick to their guns when you point
out that their traffic is traversing the web completely unencrypted). I
block default and common proxy ports such as 3128, 7212, and 6588 in
both directions. Squid is too easy to misconfigure (done it myself).
GhostSurf and WinGate have both been abusable as open proxies in various
releases. I also block 8000, 8080 and 8081 towards the customers.
These are some of our most commonly scanned ports (usually all 3 at once
plus some or all of the 80xx ones). I've encountered many compromised
residential CPEs that the users either enabled themselves or were
enabled by default. I don't block those 3 ports on outbound flows
though; too many false positives.

And finally we also block several different types of ICMPs. First off
we block ICMP fragments. Then we permit echo, echo-reply,
packet-too-big, and time-exceeded. The rest get explicitly dropped.
IPv6 will change this list dramatically. I haven't had time to research
ICMPv6 thoroughly enough to say any more than that.

Basically I just pick out some of the really bad ports and block them.
This gives me a wealth of data with which to null-route compromised PCs
scanning my networks.

> Also, is it common that the rules are based on tcp flags (e.g. SYN,
> SYN-ACK)? One would think block SYN packet is good enough.

I don't get that deep into it. Forged packets of types other than SYN
can still reek havoc on existing flows. I think it's better to block
all and move on.

Justin

lyndon at orthanc

Oct 22, 2009, 4:14 PM

Post #6 of 126 (1610 views)
Permalink

Re: ISP port blocking practice [In reply to]

> Few
> companies use the MSP port (tcp/587).

Can you elaborate. Is this based on analysis you've conducted on
your own network? And if so, is the data (anonymized) available for
the rest of us to look at?

My experience is that port 587 isn't used because ISPs block it
out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack
it with a proxy that filters out the AUTH parts of the EHLO response,
making the whole point of using the submission service ... pointless.

--lyndon

justin at justinshore

Oct 22, 2009, 4:27 PM

Post #7 of 126 (1609 views)
Permalink

Re: ISP port blocking practice [In reply to]

Zhiyun Qian wrote:
> 1). For any outgoing traffic, if the destination port is 25, then drop
> the packets.
> 2). For any incoming traffic, if the source port is 25, then drop the
> packets.

It's been pointed that I glossed over the wording of #2, specifically
missing the "source port" part of it, thus giving the right answer to
the wrong question. :-)

To answer your question, all our tcp/25 filters are based on destination
port. I could use source port but really I'm more concerned with my
customers not running SMTP servers in one direction and them not being
able to send spam in the other. Using source port needlessly
complicates those goals IMHO. Someone might have a specific reason to
use it but I don't in my case at least.

Justin

sean at donelan

Oct 22, 2009, 5:38 PM

Post #8 of 126 (1608 views)
Permalink

Re: ISP port blocking practice [In reply to]

On Thu, 22 Oct 2009, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
> My experience is that port 587 isn't used because ISPs block it
> out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack
> it with a proxy that filters out the AUTH parts of the EHLO response,
> making the whole point of using the submission service ... pointless.

You mentioned this last June. Can anyone else corroborate it? Rogers
says they don't do that, and lots of other people seem to be able to
use port 587 on Rogers (and other ISPs) without problems.

All the cases I've looked at, where someone claimed an ISP was blocking
port 587, it turned out to be some other problem. The most common reason
was related to some security software/host based firewall running on the
user's own computer.

jmaimon at ttec

Oct 22, 2009, 5:45 PM

Post #9 of 126 (1608 views)
Permalink

Re: ISP port blocking practice [In reply to]

justin at justinshore

Oct 22, 2009, 6:29 PM

Post #10 of 126 (1608 views)
Permalink

Re: ISP port blocking practice [In reply to]

Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
>> Few
>> companies use the MSP port (tcp/587).
>
> Can you elaborate. Is this based on analysis you've conducted on
> your own network? And if so, is the data (anonymized) available for
> the rest of us to look at?
>
> My experience is that port 587 isn't used because ISPs block it
> out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack
> it with a proxy that filters out the AUTH parts of the EHLO response,
> making the whole point of using the submission service ... pointless.

I can't speak for Rogers but I have analyzed our netflow captures on a
semi-regular basis for several things before flushing it, use of the MSP
port being one of them. I've never seen any MSP port traffic on my SP
network that didn't fall into 1 of 2 categories:

1) inbound scanning for MTAs listening on the MSP port, or
2) my own MSP traffic or that of family members traffic running across
my SP network that happen to use one of my personal servers for their
own email hosting.

I can also speak from experience from the enterprise customers of the
consulting side of my SP that I worked with before returning to the SP.
Not a one of them made use of the MSP port. The vast majority, I'm
sorry to say, used Microsoft Exchange which to the best of my knowledge
doesn't support RFC2476. I did a little Googling just now and couldn't
find any hits to say they did either. Some utilized RPC-over-HTTP.
Most at the time didn't, requiring direct SMTP access or VPN.

I wish more people would use it though. My users wouldn't have cause to
get so upset when I tell them that they have to pay monthly for a static
IP to use tcp/25. It would reduce my hassles a wee bit.

Justin

jmaimon at ttec

Oct 22, 2009, 6:41 PM

Post #11 of 126 (1604 views)
Permalink

Re: ISP port blocking practice [In reply to]

Justin Shore wrote:
> The vast majority, I'm
> sorry to say, used Microsoft Exchange which to the best of my knowledge
> doesn't support RFC2476.

You can configure exchange to use additional smtp virtual servers and
bind them to specific ports. You can also require authentication to
access the ports and you can restrict it to users. You can also enable
it for STARTTLS.

What I dont know is whether Exchange has or ever will support SMTPS
which is strange considering many versions of outlook default to try
that for any secured port other than 25.

> I wish more people would use it though. My users wouldn't have cause to
> get so upset when I tell them that they have to pay monthly for a static
> IP to use tcp/25. It would reduce my hassles a wee bit.

I have many a time recommended consulting customers to follow up with
their mail provider to see if they has any plans to support the rfc
standard, but I dont share much enthusiasm for complete adoption. I do
believe it is getting better.

>
> Justin
>
>

scott at doc

Oct 22, 2009, 6:46 PM

Post #12 of 126 (1605 views)
Permalink

Re: ISP port blocking practice [In reply to]

On Thu, Oct 22, 2009 at 6:29 PM, Justin Shore <justin [at] justinshore>wrote:

> I can also speak from experience from the enterprise customers of the
> consulting side of my SP that I worked with before returning to the SP. Not
> a one of them made use of the MSP port. The vast majority, I'm sorry to
> say, used Microsoft Exchange which to the best of my knowledge doesn't
> support RFC2476. I did a little Googling just now and couldn't find any
> hits to say they did either. Some utilized RPC-over-HTTP. Most at the time
> didn't, requiring direct SMTP access or VPN.
>

Depends what you mean by "support RFC2476".

Exchange most definitely supports message submission on port 587. Whether
it supports RFC2476 to the letter in terms of other requirements I don't
know, but submission as a "client access" mechanism is fully supported, with
all the usual defaults you'd expect (eg, auth required)

Of course, that doesn't mean that it'll be enabled in a specific
environment, or even if it is enabled, that it will be exposed from the
firewall. Most larger corporates will be using Outlook with Exchange, and
thus may only support RPC-over-HTTP as you've stated.

Scott

Jon.Kibler at aset

Oct 22, 2009, 7:36 PM

Post #13 of 126 (1604 views)
Permalink

Re: ISP port blocking practice [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zhiyun Qian wrote:
> Hi all,
>
> What is the common practice for enforcing port blocking policy (or what
> is the common practice for you and your ISP)? More specifically, when
> ISPs try to block certain outgoing port (port 25 for instance), they
> could do two rules:
> 1). For any outgoing traffic, if the destination port is 25, then drop
> the packets.
> 2). For any incoming traffic, if the source port is 25, then drop the
> packets.
>
> Note that either of the rule would be able to block outgoing port 25
> traffic since each rule essentially represent one direction in a TCP
> flow. Of course, they could apply both rules. However, based on our
> measurement study, it looks like most of the ISPs are only using rule
> 1). Is there any particular reason why rule 1) instead of rule 2)? Or
> maybe both?
>
> Also, is it common that the rules are based on tcp flags (e.g. SYN,
> SYN-ACK)? One would think block SYN packet is good enough.
>
> Regards.
> -Zhiyun

I understand your question, and I believe that you have been given a lot of good
answers. However, I believe that, as an ISP, you are asking the wrong question;
more precisely, you are only asking part of the real question you should be
asking. The more appropriate question should be: "What should be our network
filtering policies?"

To answer that question, I would start with ingress and egress filtering by IP
address, protocol, etc.:
1) Never allow traffic to egress any subnet unless its source IP address is
within that subnet range.
2) Never allow traffic to egress any subnet, if that traffic claims to
originate from the subnet's network number or broadcast address.
3) Never allow traffic to ingress any subnet, if that traffic is directed to
the subnet's network number or broadcast address.
4) Never allow traffic to ingress any network if the source address is bogus.
5) Never allow traffic to ingress or egress any network if it has an protocol
not "supported" by your network (e.g., allow only TCP, UDP, ICMP, ESP, AH, GRE,
etc.).
6) Never allow traffic to ingress or egress any network if it has an invalid
TCP flags configuration.

These are the rules I can think of off the top of my head without looking at an
actual hardened router. I am sure I am missing some, but these are a good start.

My $0.02 worth.

Jon
- --
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC USA
o: 843-849-8214
c: 843-813-2924
s: 843-564-4224
s: JonRKibler
e: Jon.Kibler [at] aset
e: Jon.R.Kibler [at] gmail
http://www.linkedin.com/in/jonrkibler

My PGP Fingerprint is:
BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrhFp0ACgkQUVxQRc85QlOYlgCggttgagm2sb90Vg7ntEreFtLr
ydAAnjG4zEmkTmLuZpWUey9nNRHZiTLs
=VDEG
-----END PGP SIGNATURE-----

==================================================
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.

justin at justinshore

Oct 22, 2009, 7:51 PM

Post #14 of 126 (1604 views)
Permalink

Re: ISP port blocking practice [In reply to]

Joe Maimon wrote:
> You can configure exchange to use additional smtp virtual servers and
> bind them to specific ports. You can also require authentication to
> access the ports and you can restrict it to users. You can also enable
> it for STARTTLS.

That I did not know. Last time I'd looked there wasn't a decent work
around unless you wanted to run a 2nd Exchange server in a cluster of
sorts on a 2nd box and change it's default port to 587. Then let
Exchange clustering move the mail around on the back end. This is good
to know.

> I have many a time recommended consulting customers to follow up with
> their mail provider to see if they has any plans to support the rfc
> standard, but I dont share much enthusiasm for complete adoption. I do
> believe it is getting better.

I'm sorry to say that the larger SP that we outsourced our customer mail
service to doesn't support MSP. They don't support much of anything
outside of the very basics. They require SMTP AUTH but until relatively
recently they didn't support any AUTH options other than plaintext (I
was actually shocked just now when I doublechecked because I have looked
before). No, I'm not kidding. They do rDNS checks on every IP list in
a Received line. The also do DNSBL DUL checks on all IPs on the
Received lines (dumb because of course the first one will match if the
SP has their customer dynamic pools listed in a DUL-type list). Things
will change on their end and the way we find out is because of user
complaints. The decision to switch to them wasn't a technical one I'm
afraid. If you're an Internet *Service* Provider you should probably
provide you own services.

Justin

steve at ibctech

Oct 22, 2009, 8:26 PM

Post #15 of 126 (1602 views)
Permalink

Re: ISP port blocking practice [In reply to]

Sean Donelan wrote:
> On Thu, 22 Oct 2009, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
>> My experience is that port 587 isn't used because ISPs block it
>> out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack
>> it with a proxy that filters out the AUTH parts of the EHLO response,
>> making the whole point of using the submission service ... pointless.
>
> You mentioned this last June. Can anyone else corroborate it? Rogers
> says they don't do that, and lots of other people seem to be able to
> use port 587 on Rogers (and other ISPs) without problems.
>
> All the cases I've looked at, where someone claimed an ISP was blocking
> port 587, it turned out to be some other problem. The most common
> reason was related to some security software/host based firewall running
> on the user's own computer.

Please pardon my ignorance here, especially if I've mistaken context...

Although I'm not an email engineer, it was at *least* three-1/2 years
ago that we switched our users from sending on port 25, to auth over 587
('users' meaning the clients we have as an ISP/hosting company, which
can establish on 587 from within OR without our network).

Although I can recall a few edge cases that were brought to my attention
for clients (users) not able to submit from a different network, the
collateral damage has been ~1%. (ironically however, it seems as though
recently those who have gone with a 'stick' have been reporting issues,
and we've had to have them switch to port 25 on the SMTP server within
the relevant network).

I never even imagined that someone would do port 587 blocking as such.

I'll have to light up on the network of the next client that complains,
and if 587 doesn't get through, I'll start advising the helpdesk that
they should redirect the former-client to call the 'ISP'.

Someone please tell me that I'm misunderstanding something, so that I
don't feel that two years of client notices, research and
implementation, and another two years of dealing with manual support
calls because they didn't 'see' the 400 warnings of email changes wasn't
all a waste.

fwiw to keep on topic, I block all 25-in with a small exception list for
a few colo boxes, and our incoming MTA collection/filtering cluster.

This 'in' ACL is placed on all PE hardware. The incoming mail cluster is
attached to it's own PE, which ensures that everything from anywhere on
the network eventually filters through this ACL, and that the core is
always essentially clean.

I then pretty much do the same out-25 on all PE hardware. Because my
network is small, I manually/strictly manage the ACLs on any PE that is
Internet/Peer facing.

colo servers that require SMTP services is either connected to a PE
designed to allow it, or is put into a VLAN designed for such. afair, I
have only two clients remaining that I haven't forced into a /29 corner
where I can SWIP their space, thereby using the 'you're responsible'
hammer. Either way, even without the swip, I've made them well aware of
the repercussions of failing to at least be attentive.

Steve

owen at delong

Oct 22, 2009, 8:38 PM

Post #16 of 126 (1601 views)
Permalink

Re: ISP port blocking practice [In reply to]

On Oct 22, 2009, at 3:39 PM, Justin Shore wrote:

> Zhiyun Qian wrote:
>> Hi all,
>> What is the common practice for enforcing port blocking policy (or
>> what is the common practice for you and your ISP)? More
>> specifically, when ISPs try to block certain outgoing port (port 25
>> for instance), they could do two rules:
>> 1). For any outgoing traffic, if the destination port is 25, then
>> drop the packets.
>> 2). For any incoming traffic, if the source port is 25, then drop
>> the packets.
>
> I block on both generally. I block inbound and outbound for
> residential customers in dynamic pools. I block inbound only for
> residential with statically-assigned IPs. That way a customer can
> request (and pay for) a static IP and be able to get around out
> outbound SMTP block. Few companies use the MSP port (tcp/587). I'm
> not sure why more don't make the effort but most don't. To make up
> for that we allow static residential customers to evade that filter
> with a static IP. We still block inbound though. We also allow
> them to use our SMTP servers and SmartHosts if they want with no
> requirements on source domains (like some providers require,
> essentially requiring the customer to advertise for you). The
> inbound block isn't really all that useful as you elude to. However
> I use it more often than not to look for people scanning out ranges
> for open relays. I use that data for feed my RTBH trigger router
> and drop the spammer's traffic on the floor (or the poor,
> unfortunate owner of the compromised PC that's been 0wned.
>
Blocking ports that the end user has not asked for is bad.

Doing it and refusing to unblock is worse.

Some ISPs have the even worse practice of blocking 587 and a few even
go to the horrible length to block 465.

A few hotel gateways I have encountered are dumb enough to think they
can block TCP/53
which is always fun.

> We block several other things too. Netbios traffic gets dropped
> both ways. MS-SQL traffic gets dropped both ways (a few users have
> complained about this but very few stick to their guns when you
> point out that their traffic is traversing the web completely
> unencrypted). I block default and common proxy ports such as 3128,
> 7212, and 6588 in both directions. Squid is too easy to
> misconfigure (done it myself). GhostSurf and WinGate have both been
> abusable as open proxies in various releases. I also block 8000,
> 8080 and 8081 towards the customers. These are some of our most
> commonly scanned ports (usually all 3 at once plus some or all of
> the 80xx ones). I've encountered many compromised residential CPEs
> that the users either enabled themselves or were enabled by
> default. I don't block those 3 ports on outbound flows though; too
> many false positives.
>
> And finally we also block several different types of ICMPs. First
> off we block ICMP fragments. Then we permit echo, echo-reply,
> packet-too-big, and time-exceeded. The rest get explicitly dropped.
> IPv6 will change this list dramatically. I haven't had time to
> research ICMPv6 thoroughly enough to say any more than that.
>
> Basically I just pick out some of the really bad ports and block
> them. This gives me a wealth of data with which to null-route
> compromised PCs scanning my networks.
>
Lovely for you, but, not particularly helpful to your customers who
may actually want to use some of those services.

Owen

owen at delong

Oct 22, 2009, 8:51 PM

Post #17 of 126 (1602 views)
Permalink

Re: ISP port blocking practice [In reply to]

On Oct 22, 2009, at 4:14 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:

>> Few
>> companies use the MSP port (tcp/587).
>
> Can you elaborate. Is this based on analysis you've conducted on
> your own network? And if so, is the data (anonymized) available for
> the rest of us to look at?
>
> My experience is that port 587 isn't used because ISPs block it
> out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack
> it with a proxy that filters out the AUTH parts of the EHLO response,
> making the whole point of using the submission service ... pointless.
>
> --lyndon
>
Wow... That's evil. Most ISPs I've dealt with don't have that
problem, but,
if I encountered one that did, I'd vote with my feet in short order.

Owen

steve at ibctech

Oct 22, 2009, 9:40 PM

Post #18 of 126 (1601 views)
Permalink

Re: ISP port blocking practice [In reply to]

Jon Kibler wrote:
> Zhiyun Qian wrote:
>> Hi all,
>
>> What is the common practice for enforcing port blocking policy (or what
>> is the common practice for you and your ISP)? More specifically, when
>> ISPs try to block certain outgoing port (port 25 for instance), they
>> could do two rules:
>> 1). For any outgoing traffic, if the destination port is 25, then drop
>> the packets.
>> 2). For any incoming traffic, if the source port is 25, then drop the
>> packets.
>
>> Note that either of the rule would be able to block outgoing port 25
>> traffic since each rule essentially represent one direction in a TCP
>> flow. Of course, they could apply both rules. However, based on our
>> measurement study, it looks like most of the ISPs are only using rule
>> 1). Is there any particular reason why rule 1) instead of rule 2)? Or
>> maybe both?
>
>> Also, is it common that the rules are based on tcp flags (e.g. SYN,
>> SYN-ACK)? One would think block SYN packet is good enough.
>
>> Regards.
>> -Zhiyun
>
> I understand your question, and I believe that you have been given a lot of good
> answers. However, I believe that, as an ISP, you are asking the wrong question;
> more precisely, you are only asking part of the real question you should be
> asking. The more appropriate question should be: "What should be our network
> filtering policies?"
>
> To answer that question, I would start with ingress and egress filtering by IP
> address, protocol, etc.:
> 1) Never allow traffic to egress any subnet unless its source IP address is
> within that subnet range.

Sorry to nit, but shouldn't your uRPF setup take care of this (and many
other of your list items), long before ACL?

It's absolutely great if you have your list implemented, but imho, all
ISP's, no matter how small should investigate and implement urpf. It's
especially fun to play with RTBH.

To be honest, the smaller you are, the easier it is to implement (ie.
urpf strict everywhere! :)

Steve

Valdis.Kletnieks at vt

Oct 22, 2009, 10:29 PM

Post #19 of 126 (1597 views)
Permalink

Re: ISP port blocking practice [In reply to]

On Thu, 22 Oct 2009 22:36:13 EDT, Jon Kibler said:

> 4) Never allow traffic to ingress any network if the source address is bogus.

4a) Never flag a source address as bogus unless you can verify it is bogus
*today*, not when you installed the filter. Out of date bogon filters are evil.

Jon.Kibler at aset

Oct 23, 2009, 2:14 AM

Post #20 of 126 (1593 views)
Permalink

Re: ISP port blocking practice [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve Bertrand wrote:
> Jon Kibler wrote:
>> To answer that question, I would start with ingress and egress filtering by IP
>> address, protocol, etc.:
>> 1) Never allow traffic to egress any subnet unless its source IP address is
>> within that subnet range.
>
> Sorry to nit, but shouldn't your uRPF setup take care of this (and many
> other of your list items), long before ACL?
>
> It's absolutely great if you have your list implemented, but imho, all
> ISP's, no matter how small should investigate and implement urpf. It's
> especially fun to play with RTBH.
>
> To be honest, the smaller you are, the easier it is to implement (ie.
> urpf strict everywhere! :)
>
> Steve
>

Agree for the most part. However:

1) The overwhelming majority of routers I have audited do not have uRPF
implemented and most admins do not comprehend it, but they do comprehend
(usually) ACLs.

2) L3 switching does not always support it, leaving potential for abuse if the
network has any donut holes.

3) uRPF works best on egress but does little on outside ingress (e.g., bogons).

4) Defense in depth dictates using more than one way to detect an attack, so use
both ACLs and uRPF.

Jon
- --
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC USA
o: 843-849-8214
c: 843-813-2924
s: 843-564-4224
s: JonRKibler
e: Jon.Kibler [at] aset
e: Jon.R.Kibler [at] gmail
http://www.linkedin.com/in/jonrkibler

My PGP Fingerprint is:
BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrhc+gACgkQUVxQRc85QlNAgACfZgrSuZ7dC1A38oIXB3lInUOc
FnIAniWiQcVpJzp/ooh4LOHwEzPXUWo3
=dKbZ
-----END PGP SIGNATURE-----

==================================================
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.

steve at ibctech

Oct 23, 2009, 5:36 AM

Post #21 of 126 (1578 views)
Permalink

Re: ISP port blocking practice [In reply to]

Jon Kibler wrote:
> Steve Bertrand wrote:
>> Jon Kibler wrote:
>>> To answer that question, I would start with ingress and egress filtering by IP
>>> address, protocol, etc.:
>>> 1) Never allow traffic to egress any subnet unless its source IP address is
>>> within that subnet range.
>> Sorry to nit, but shouldn't your uRPF setup take care of this (and many
>> other of your list items), long before ACL?
>
>> It's absolutely great if you have your list implemented, but imho, all
>> ISP's, no matter how small should investigate and implement urpf. It's
>> especially fun to play with RTBH.
>
>> To be honest, the smaller you are, the easier it is to implement (ie.
>> urpf strict everywhere! :)
>
>> Steve
>
>
> Agree for the most part. However:
>
> 1) The overwhelming majority of routers I have audited do not have uRPF
> implemented and most admins do not comprehend it, but they do comprehend
> (usually) ACLs.

Fair enough. However, a considerable portion of my PE and CE gear
consists of 2691's in which uRPF is enabled, so I'd have to wonder which
hardware doesn't support it. Even my routers running FreeBSD/Quagga have
it enabled.

Aside from that, I truly did mean kudos for the poster for at least
putting in the effort for configuring such an elaborate ACL setup :)

As for the admins not comprehending it, imho, if someone is in a
position of operating an Internet Provider network, particularly one
that utilizes BGP, they need to comprehend it, if even just for the
respect of the community. IIRC, it was about two weeks after I read
Kumari's initial draft that I had it not only understood, but implemented.

Even given the small scale that I am at, it really sucks when you see
BOGON/your own prefixes ingress to your network. What's more upsetting,
is when you have made more than one request to an upstream to stop it,
and you get no response...at all.

> 2) L3 switching does not always support it, leaving potential for abuse if the
> network has any donut holes.

I didn't think of that angle. My experience with L3 switching is very
limited. My understanding is though that most ops use L3 switching
closer to the core (as opposed to the edge), where uRPF isn't needed
anyhow.

> 3) uRPF works best on egress but does little on outside ingress (e.g., bogons).

Unless you have implemented an automated s/RT(BH|sink). Cymru bogons
(learnt via peering) on a trigger box, pushed in through a route-map
tagged with the null-route community to the PE. Works magic.

> 4) Defense in depth dictates using more than one way to detect an attack, so use
> both ACLs and uRPF.

I completely agree. Useful not only as depth, but to patch the holes
where one can't implement strict uRPF due to a client having multiple
peer-points within your network.

Cheers,

Steve

justin at justinshore

Oct 23, 2009, 7:47 AM

Post #22 of 126 (1567 views)
Permalink

Re: ISP port blocking practice [In reply to]

Owen DeLong wrote:
> Blocking ports that the end user has not asked for is bad.

I was going to ask for a clarification to make sure I read your
statement correctly but then again it's short enough I really don't see
any room to misinterpret it. Do you seriously think that a typical
residential user has the required level of knowledge to call their SP
and ask for them to block tcp/25, tcp & udp/1433 and 1434, and a whole
list of common open proxy ports? While they're at it they might ask the
SP to block the C&C ports for Bobax and Kraken. I'm sure all
residential users know that they use ports 447 and 13789. If so then
send me some of your users. You must be serving users around the MIT
campus.

> Doing it and refusing to unblock is worse.

How you you propose we pull a customer's dynamically-assigned IP out of
a DHCP pool so we can treat it differently? Not all SPs use
customer-facing AUTH. I can think of none that do for CATV though I'm
sure someone will now point an oddball SP that I've never heard of before.

> Some ISPs have the even worse practice of blocking 587 and a few even
> go to the horrible length to block 465.

I would call that a very bad practice. I haven't personally seen a
mis-configured MTA listening on the MSP port so I don't think they can
make he claim that the MSP port is a common security risk. I would call
tcp/587 a very safe port to have traverse my network. I think those
ISPs are either demonstrating willful ignorance or marketing malice.

> A few hotel gateways I have encountered are dumb enough to think they
> can block TCP/53
> which is always fun.

The hotel I stayed in 2 weeks ago that housed a GK class I took had just
such a proxy. It screwed up DNS but even worse it completely hosed
anything trying to tunnel over HTTP. OCS was dead in the water. My
RPC-over-HTTP Outlook client couldn't work either. Fortunately they
didn't mess with IPSec VPN or SSH. Either way it didn't matter much
since the network was unusable (12 visible APs from room, all on
overlapping 802.11b/g channels). The average throughput was .02Mbps.

> Lovely for you, but, not particularly helpful to your customers who may
> actually want to use some of those services.

I take a hard line on this. I will not let the technical ignorance of
the average residential user harm my other customers. There is
absolutely no excuse for using Netbios or MS-SQL over the Internet
outside of an encrypted tunnel. Any user smart enough to use a proxy is
smart enough to pick a non-default port. Any residential user running a
proxy server locally is in violation of our AUP anyway and will get
warned and then terminated. My filtering helps 99.99% of my userbase.
The .001% that find this basic security filter intolerable can speak
with their wallets. They can find themselves another provider if they
want to use those ports or pay for a business circuit where we filter
very little on the assumption they as a business have the technical
competence to handle basic security on their own. (The actual
percentage of users that have raised concerns in the past 3 years is
.0008%. I spoke with each of them and none decided to leave our service.)

We've been down the road of no customer-facing ingress ACLs. We've
fought the battles of getting large swaths of IPs blacklisted because of
a few users' technical incompetence. We've had large portions of our
network null-routed in large SPs. Then we got our act together and
stopped acting like those ISPs who we all love to bitch about, that do
not manage their customer traffic, and are poor netizens of this shared
resource we call the Internet. Our problems have all but gone away.
Our residential and business users no longer call in on a daily basis to
report blacklisting problems. We no longer have reachability issues
with networks that got fed up with the abuse coming from our compromised
users and null-routed us. I stand by our results as proof that what
we're doing is right. Our customers seem to agree and that's what matters.

Justin

cboyd at gizmopartners

Oct 23, 2009, 8:25 AM

Post #23 of 126 (1563 views)
Permalink

Re: ISP port blocking practice [In reply to]

On Oct 22, 2009, at 6:14 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:

> My experience is that port 587 isn't used because ISPs block it
> out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack
> it with a proxy that filters out the AUTH parts of the EHLO response,
> making the whole point of using the submission service ... pointless.

We use 587 quite a lot (with SMTP Auth and SSL/TLS), and have found
_very_ few places block or proxy it. We don't have any/many customers
in Rogers service areas though.

The biggest reason people don't use it is that it requires some
thought and tweaking settings in the "advanced" tab areas of many
email clients. Newer email clients are actually starting to look for
submission port and SSL support and configuring it autmatically if
they find it.

Once it's set up correctly we've found customers really like it since
their email "just works" in most places.

--Chris

jbates at brightok

Oct 23, 2009, 8:27 AM

Post #24 of 126 (1563 views)
Permalink

Re: ISP port blocking practice [In reply to]

Chris Boyd wrote:
> Once it's set up correctly we've found customers really like it since
> their email "just works" in most places.
>

We get the same response. The largest 587 usage we have currently,
though, is cell/PDA.

Jack

steve at ibctech

Oct 23, 2009, 8:35 AM

Post #25 of 126 (1563 views)
Permalink

Re: ISP port blocking practice [In reply to]

Chris Boyd wrote:
>
> On Oct 22, 2009, at 6:14 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
>
>> My experience is that port 587 isn't used because ISPs block it
>> out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack
>> it with a proxy that filters out the AUTH parts of the EHLO response,
>> making the whole point of using the submission service ... pointless.
>
> We use 587 quite a lot (with SMTP Auth and SSL/TLS), and have found
> _very_ few places block or proxy it. We don't have any/many customers
> in Rogers service areas though.
>
> The biggest reason people don't use it is that it requires some thought
> and tweaking settings in the "advanced" tab areas of many email
> clients. Newer email clients are actually starting to look for
> submission port and SSL support and configuring it autmatically if they
> find it.
>
> Once it's set up correctly we've found customers really like it since
> their email "just works" in most places.

I completely agree, and after all was said and done, well worth the effort.

Even today, if users use their age-old setup manual to set up an email
application, they can receive, but not send. We know why immediately
when they call in and state this, and we tell them to expect an email to
fix it, and then send them something like this:

http://eagle.ca/update/mail/Outlook_Express/index.html

...yes, believe it or not, even with the pictures, they will sometimes
still get it wrong ;)

Years in planning and implementation, but a good, large-scale learning
exercise and the achievement of no port 25 that I'm very proud of.

Steve

1 2 3 4 5 6

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads