[118487] in North American Network Operators' Group
Re: ISP port blocking practice
daemon@ATHENA.MIT.EDU (Valdis.Kletnieks@vt.edu)
Thu Oct 22 13:35:27 2009
To: Zhiyun Qian <zhiyunq@umich.edu>
In-Reply-To: Your message of "Thu, 22 Oct 2009 13:22:17 EDT."
<0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu>
From: Valdis.Kletnieks@vt.edu
Date: Thu, 22 Oct 2009 13:33:17 -0400
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--==_Exmh_1256232797_3496P
Content-Type: text/plain; charset=us-ascii
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...
--==_Exmh_1256232797_3496P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iD8DBQFK4JddcC3lWbTT17ARAuBEAJ46EH+fDVW42Bz12SKL/4tb+P+vZQCgmKcT
ppRkedKSQffVEAMSyJolwgE=
=UcKt
-----END PGP SIGNATURE-----
--==_Exmh_1256232797_3496P--
