Re: ISP port blocking practice

["mark [at] edgewire" <mark () edgewire sg>]

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,

Mark

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