ISP port blocking practice
mark [at] edgewire
mark at edgewire.sg
Tue Nov 3 19:51:30 CST 2009
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.
On 04-Nov-2009, at 4:21 AM, Ron Bonica wrote:
> 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?
> (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
>>> is the common practice for you and your ISP)? More specifically,
>>> 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
>>> the packets.
>>> 2). For any incoming traffic, if the source port is 25, then drop
>> I block on both generally. I block inbound and outbound for
>> customers in dynamic pools. I block inbound only for residential
>> statically-assigned IPs. That way a customer can request (and pay
>> 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
>> 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
>> 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
>> for you). The inbound block isn't really all that useful as you
>> 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
>> releases. I also block 8000, 8080 and 8081 towards the customers.
>> These are some of our most commonly scanned ports (usually all 3 at
>> plus some or all of the 80xx ones). I've encountered many
>> 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
>> 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
>> ICMPv6 thoroughly enough to say any more than that.
>> Basically I just pick out some of the really bad ports and block
>> This gives me a wealth of data with which to null-route compromised
>> 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
>> can still reek havoc on existing flows. I think it's better to block
>> all and move on.
More information about the NANOG