ISP port blocking practice

mark [at] edgewire mark at
Wed Nov 4 01:51:30 UTC 2009

Hi all,

Just out of curiosity for those whom may manage Hotel Wifi networks (I  
know I know, not really ISP level but since we're on the topic of port  
blocking). Does anyone actually make an effort to be blocking port  
443? I've had that experience at a few Hotels in Philippines and I  
can't think of a valid reason as to why those ports would be dropping  
traffic. Would like to hear from anyone whom has had this experience.

Best regards,


On 04-Nov-2009, at 4:21 AM, Ron Bonica wrote:

> 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