0

Our network admins/security admin make the case that we should keep common (external facing) ports (FTP, XMPP, IMAP, IPSEC) closed as it is a greater security risk and makes us more susceptible to attack. While I can appreciate that these choices are made with security in mind, it tends to make work difficult at best and challenging at worse for our end-users/staff/consultants.

Does blocking commonly used ports make our overall network more secure?

2
  • Are you referring to inbound traffic or outbound traffic?
    – joeqwerty
    Aug 11, 2011 at 16:02
  • Outbound traffic.
    – user24280
    Aug 11, 2011 at 16:06

2 Answers 2

3

I think you're referring to egress filtering?

It's simply a question of what level of risk is acceptable to your organization, really. As far as whether it increases security, I'd answer with a qualified yes - generally speaking, it's a good security step, but it needs to be done well to be effective (I'd be surprised if they were just blocking certain ports specifically - more likely, they're allowing only certain whitelisted ports).

Example scenarios where it'd be of use are security issues like botnet zombie reporting and spam relaying, as well as policy/bandwidth use issues like bittorrent or streaming video.

The approach you should probably take would be to state the business case for a protocol's allowance - and try to find middle ground, if needed, like allowing IMAP only to approved servers. Remember, there's likely a policy reason that it was put in place.

1
  • I do believe they have a whitelist. I know we definitely block potentially nasty/bandwidth consuming stuffs (e.g., bittorrent, kazaa).
    – user24280
    Aug 11, 2011 at 16:20
1

I'm going to differ with the answers already here, and say no, almost certainly not. If you have any of your systems externally, then allowing unencrypted connections to them might expose eg login IDs that you have an interest in keeping secure, but since we're talking egress filtering I'm guessing you don't have any such systems out there, so by blocking unencrypted services (ftp, pop, imap) you're only protecting other people's secrets, and that's not your job.

Moreover, it's pointless. As long as you allow port 443 outbound - and there would be a riot in any organisation I've ever worked in if that was forbidden - you've got users making SSL-encrypted tunnels out of the building left, right, and centre, and you have no idea what they're passing through them. Could be HTTP, sure, but it could also be SSH, could be IMAP, could be OpenVPN, could be anything at all as long as it's inside that SSL-encrypted tunnel.

So sure, you can annoy people by blocking other ports outbound, but as long as you're allowing HTTPS it's utterly pointless from a security standpoint; it won't prevent a determined adversary for more than a minute, and it'll really annoy all your legitimate users.

5
  • I'd argue that there's security value in preventing stupid people from doing stupid things, even though you aren't going to be able to block a smart user from tunneling out over 443. And some organizations require outbound 443 traffic to go through a proxy for just this reason. Aug 11, 2011 at 16:22
  • You can't proxy https traffic without breaking all the certification, unless you have a prozy that decrypts all traffic in both dreictions, resigns it, and the browser has a CA specific to the re-signing device. These do exist, but it's not simple.
    – MadHatter
    Aug 11, 2011 at 17:15
  • Yes, and there's another security vs usability tradeoff in that the proxy must be the one doing all the validating of remote certificates - no browser warnings on a bad cert, just a page that won't load. For the CA, if you've got an internal root that's already trusted by clients, it's just a matter of giving the proxy a subordinate CA. Having deployed a solution like this at my last job, I feel confident in saying "people do this". Aug 11, 2011 at 17:21
  • As I said, these do exist; I agree with you, it can be done, and it is. But as you've pointed out, it requires deploying an internal CA to all desktops, and there are other tradeoffs, too. If you're not going to those lengths, then blocking outbound TCP is fairly pointless. If you are going to those lengths, then application-level proxying every business-approved protocol is within your grasp, and the question still doesn't apply, because you won't be allowing anything directly outbound from the desktop.
    – MadHatter
    Aug 11, 2011 at 18:47
  • Yup, completely agreed (and +1). Aug 11, 2011 at 18:50

You must log in to answer this question.