On Oct 22, 2009, at 3:39 PM, 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.
Blocking ports that the end user has not asked for is bad.
Doing it and refusing to unblock is worse.
Some ISPs have the even worse practice of blocking 587 and a few even
go to the horrible length to block 465.
A few hotel gateways I have encountered are dumb enough to think they
can block TCP/53
which is always fun.
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.
Lovely for you, but, not particularly helpful to your customers who
may actually want to use some of those services.
Owen
