16

I've always been taught/believed that with a corporate firewall, you block all outgoing traffic to start, then open up only the holes you need for specific traffic. This makes sense to me from both the "controlling what users send out of our network" and the "controlling the damage malware can do" perspectives. I started in IT in the mid 90s, and I've always understood this to be the best practice.

I'm now managing a firewall admin who does not seem to share this philosophy. He expected our firewall to allow all outgoing traffic. I understand that this is the way many SOHO* firewalls are configured out of the box, but I'm troubled that an enterprise firewall admin would think this way.

Am I being an old woman about it, or is my concern legit? Is it normal these days for corporate/enterprise firewalls to allow all outgoing traffic?

* Small Office / Home Office

Improve this question
1
  • 1
    I haven't looked at the Cisco stuff lately, but last time I setup a Cisco PIX/ASA, the default policies were set to permit outgoing, and block incoming. So this type of setup isn't exclusively for soho stuff.
    – Zoredache
    Dec 13, 2012 at 0:14

6 Answers 6

Reset to default
13

It's common and it's bad.

I've fixed this in the past. In one large financial org, it took about 4 hours per week for two years.

  • Step 1: Approve and communicate new policy to block unapproved P2P apps. Block them.
  • Step 2: Monitor outbound port 25, identify legit traffic, speak with the teams originating it, fix it or create exceptions. Impose the new rule.
  • Step 3: Install a proxy. Repeat Step 2 for port 80 and 443 (excepting the proxy)
  • Step 4: Monitor the user segment for other outbound traffic. Communicate with teams, document exceptions.
  • Step 5: Block everything else outbound in the user segment.
  • Step 6: Monitor the DMZ segment for other outbound traffic. Communicate with teams, document exceptions.
  • Step 7: Block everything else outbound in the DMZ segment.

Each step incrementally improves your security and makes the company more comfortable with the changes. You need to respond to problems as they crop up. Which burns more time.

Changing it all at once might work... but it will be hell and in the end, you won't have the processes and documentation to show for it, just a swiss cheese of late nights from teams screaming that the XYZ is broken or the Dobson report is not generating anymore.

If you're talking about a very small organization, just do it all at once and let people scream. You can respond quickly without separation of duties so it's more cost effective.

In a large org, everything is a change record or incident. Breaking things will be a lot more expensive than your time plodding through it all.

Improve this answer
11
  • 2
    This is a nicely laid out process, and it is standard, but is it necessary? What quantifiable risks have been mitigated? In other words, why is it bad?
    – schroeder ♦
    Dec 12, 2012 at 0:35
  • 4
    Quietly allowing this stuff is throwing information away and making things very easy for malware. E.g, when somebody tries to connect outbound on port 25, it might be an infected system transmitting spam, or an unauthorized system (e.g., personal laptop). When somebody tries to connect to a common set of ports for command and control, it should trigger alerts (and not be permitted). Allowing this stuff could cause serious problems like getting your company on a spam RBL or quietly allow malware to pierce the firewall.
    – mgjk
    Dec 12, 2012 at 14:36
  • 1
    That's understandable, but how does the situation change if malware uses port 80?
    – schroeder ♦
    Dec 12, 2012 at 15:25
  • 4
    If the malware gets past the antivirus, reads the browser configuration, learns the proxy, and gets past any content filters, then it'll get through. But most malware isn't doing that. Whereas unauthorized workstations probably aren't configured to use the proxy and will trigger the alert on the outbound port 80 request. If you're using transparent proxies it's harder, but malware-aware content filtering can help.
    – mgjk
    Dec 12, 2012 at 15:40
  • 2
    +1 Then I think you've hit on the larger point, which might be of critical interest to the OP. It's not the firewall that is the key here, but rather deep packet analysis and proxies. Knowing what is going thru your firewall more than blindly blocking.
    – schroeder ♦
    Dec 12, 2012 at 16:15
10

Your difference of opinion is exactly the difference between two distinct philosophies regarding network access control. These philosophies also demonstrate the classic trade-off between security and usability.

Blacklisting, similar to your firewall admin's stance, is a practice of allowing all but a defined list of traffic patterns through. This is the easiest to do in terms of usability and administration, but is rather insecure and borderline naive. To claim blacklisting is safe, is to presume that you know all possible threats to your network and have added them all to your deny list. To know all possible threats is obviously impossible and, even then, to selectively include all those threats on a deny list would cause the list to be enormous and unmanageable.

Whitelisting, the philosophy you were "raised with" (so to speak), is the exact opposite. It presumes all traffic should be denied, except for that which is specified in your allow list. This is the more secure option, but can also have a great impact to usability and management overhead. It is based upon the "Principle of least..." rule of security - you only allow your users/computers/programs/etc. to do what they really need to do. The up-side to this is that you know exactly what it is that your network is allowed to do. While this alone will not make you immune to all threats, it will help protect you against a good portion of the unknowns. There will still be ways to circumvent this (e.g.: with tunneling through allowed ports/protocols) but it will be much more difficult than against a blacklist-oriented approach. Of course, the down-side to this approach is that it can often be more difficult to troubleshoot problems with networked applications while still maintaining the "Principle of least..." rule.

Each approach has its merits, and its weaknesses. In the end, it is up to you (or your company's executives) to decide which approach is most reasonable for your organization. A good defense-in-depth approach that includes protective measures other than just the perimeter firewall is also essential to mitigating risks left open by whatever firewall configuration or hardware you choose.

Improve this answer
2

Having an implicit deny at the bottom of the firewall ACL is standard. He's being lazy on allowing all outgoing traffic. This is a bot net's dream.

Basically if you infect a machine that machine can now initiate a conversation on any port back to the command and control server.

  • Or, if you have a proxy people have to go through for filtering they can just turn off the proxy and bypass your filtering.
  • Or they can now bypass your email firewall and spam out directly.
  • Or they can bypass the data loss prevention you have set up on your email firewall.

Hell your security zones don't matter at that point because he has an implicit allow. So if an attacker gets one box on your network that box can get anywhere inside. Oh the possibilities. Pure genius.

Improve this answer
3
  • 3
    Although a firewall can help contain things, it's very trivial to just use port 80 as an attacker. In fact, it's smart to use port 80 or 443 because it's such a common port. It won't jump out when viewing port statistics, so any smart attacker will do this. A default-deny policy is so incredibly annoying as a power user, and it helps only so much.
    – Luc
    Dec 11, 2012 at 23:57
  • 2
    Secondly, "get on one box and get anywhere in the network" is not a result of opening outgoing ports, but of allowing communication between clients in the network. Thirdly, you're not really smart if you allow internet access without going through proxy (so it's bypassable by turning it off). What is the proxy's purpose then?
    – Luc
    Dec 11, 2012 at 23:58
  • 1
    Luc, What he's saying is he has a security zone with an: any to any on IP rule at the bottom. That's an implicit allow. That means any clients in that zone can get to anything including all your internal IPs.
    – k to the z
    Dec 13, 2012 at 20:18
1

From a stateful perspective, allowing all new outgoing connections is common as a default. The idea is that users are making new connections to servers outside of the network. If you use a whitelisting approach and only allow ports 80 and 443 out, then you do block things like botnets from using their foothold in your network from calling home on non-standard ports (6667), unless they use port 80, which is almost always open.

There might be a valid discussion about the quantified risks of allowing all new outgoing connections, but the 'safer' approach is to whitelist outgoing connections, even though you aren't protecting your network much more than allowing them all.

In my case, I am very interested in knowing what traffic is outgoing on unusual ports and to know what is being communicated, but I have resources to make that analysis valuable to me.

Improve this answer
0

First, firewalls employ a positive security model, which means that they whitelist known good, and everything else is blocked. The alternative is a negative security model, also known as blacklisting. Positive security models are best practice, period.

Does your firewall admin have a history as a network admin? My history is that a lot of network admins turned firewall admins think that way, since network admins are all about allowing communications, and are not very security minded. A lot of security holes are because network admins configured the base architecture of many companies (before security concerns were as predominant) and that is something which is very hard to reverse.

You have a legit concern, and it is NOT best practice for enterprise firewalls to allow all outgoing traffic. This is the number 1 reason that data exfiltration is successful.

In my opinion, as a security professional I would also look to do SSL decryption and application layer filtering so that you don't just open port 443 or 80, but also only specific applications through those ports. However, that is sometimes a hard sell to non-security focused organizations. False positives (Denying legitimate traffic) do occur, especially with custom built applications.

Improve this answer
-1

My 2c from the standard hacker at your company. Please note that I dont, and never have done this, it's only theory. Blocking ports is useless because:

  • You have to allow HTTPS. Allowing HTTPS enables me to bypass all restrictions and communicate with my personal VPS on port 443. After that, I can do all things that SSH enables, included but not limited to: downloading files forbidden by the proxy, browsing the web using my VPS as a proxy and creating a reverse SSH tunnel from the remote server that would allow me to access any port in my computer through the internet.

So, it could be that the standard practice is to "disable all ports and feel safe", but you need to enable encripted communications, which effectively make all your firewall rules moot.

Plus, there are perfectly benign excuses for using SSH on port 443.

Again, just my 2c, it's not worth the massive pain in the ass for your users.

Improve this answer
11
  • 1
    I feel that my "having to allow HTTPS" could be debatable. Even more debatable would be the necessity of allowing HTTPS towards everywhere (versus a small list of known servers, say, Amazon balancers, and networks, e.g. Google). Having access to a personal machine outside the premises would be limited to a few developers and tech savvy people who should be trusted to know what they're doing.
    – LSerni
    Dec 12, 2012 at 0:20
  • Yeah, I don't know. I think there are too many websites out there that require https to go one by one, whitelisting. Again, could I connect to my SSH over port 80? Not quite sure what the difference would be between those two ports. The main advantage for the sysadmin would be the possibility of actually detecting rogue encrypted traffic, but then again, you need to enable HTTPs.
    – droope
    Dec 12, 2012 at 2:47
  • Might as well not allow employees access to the internet :P That'd be safer.
    – droope
    Dec 12, 2012 at 2:47
  • 1
    That is exactly the point. You may need access to Google, or GMail; selected sites (travel agencies, banks); I can see how some developers might need access to "anywhere" to connect to unforeseen user forums and mailing list digests; but why would your run-of-the-mill employee need access to "THE INTERNET"? ...however, an easy way out of most lawyering is usually supplied by a simple proposal: HTTPS is logged. Not even proxied, just logged. URIs only. Reasons why employees need unlogged access in addition to unlimited access are thinner on the ground -- and funnier to watch.
    – LSerni
    Dec 12, 2012 at 7:25
  • 2
    What you should be suggesting is SSL decryption and application layer inspection, NOT telling people that blocking ports is useless. Bad advice.
    – JZeolla
    Dec 12, 2012 at 13:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy