[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ISP port blocking practice
- Subject: ISP port blocking practice
- From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
- Date: Thu, 22 Oct 2009 13:33:17 -0400
- In-reply-to: Your message of "Thu, 22 Oct 2009 13:22:17 EDT." <[email protected]>
- References: <[email protected]>
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.bin>