ISP port blocking practice

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Thu Oct 22 17:33:17 UTC 2009


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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20091022/2f5764d6/attachment.sig>


More information about the NANOG mailing list