ISP port blocking practice

Ron Bonica rbonica at juniper.net
Tue Nov 3 14:21:36 CST 2009


Folks,

I would love to see the IETF OPSEC WG publish a Best Common Practices
document on ISP Port filtering. The document would capture information
similar to that offered by Justin.

Would anybody on this list be willing to author an Internet Draft?

                                     Ron
                                     (co-director IETF O&M Area)

Justin Shore 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.
> 
> 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
> 
> 
> .
> 




More information about the NANOG mailing list