ISP port blocking practice
zhiyunq at umich.edu
Thu Sep 2 16:59:57 CDT 2010
Sorry for bringing this old topic back. But we have made some academic effort investigating the spamming behaviors using assymetric routing (we named it "triangualr spamming"). This work appeared in this year's IEEE Security & Privacy conference. You can take a look at it if you are interested (and feedbacks are welcome):
One of the high-level findings is that we developed probing techniques to verify that indeed most ISPs are only blocking 1) "outgoing traffic of destination port 25" instead of 2) "incoming traffic with source port 25", which means that these ISPs are vulnerable to the assymetric routing attack.
Finally, many thanks to all your useful inputs :)
On Oct 22, 2009, at 12:33 PM, Valdis.Kletnieks at vt.edu wrote:
> 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
>> 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...
More information about the NANOG