ISP port blocking practice

Mailman List Mirror (Read Only)
1

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

2

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@lava.net

3

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

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

4

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

5

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

6

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

7

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

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

8

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.

9

Sean Donelan wrote:

10

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

11

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.

12

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

13

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@aset.com
e: Jon.R.Kibler@gmail.com
http://www.linkedin.com/in/jonrkibler

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

14

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

15

Sean Donelan 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

16

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

17

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

18

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! :slight_smile:

Steve

19

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.

20

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! :slight_smile:

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@aset.com
e: Jon.R.Kibler@gmail.com
http://www.linkedin.com/in/jonrkibler

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