37

It's become standard fare for security minded organisations to block everything other than 80 and 443. As a result, more and more applications (other than web browsers) are learning to use these ports for their needs too.

Naturally malicious programs do that too, which then means that to have any real security, firewalls have to actually examine the data stream and block based on application data instead of just ports...

This seems to indicate that port based blocking was a short sighted approach to begin with, kind of like input validation solely on client...

In that case, should we not stop blanket blocking nonstandard ports, and go for more fine grained filtering in the first place...? Or are there other reasons to keep the port-whitelist approach?

Improve this question
6
  • 5
    Yes it is a quite stupid approach, it doesnt work against bad guys.
    – Uwe Burger
    Commented Dec 23, 2014 at 18:45
  • 8
    today!? It wasn't useful yesterday and it's certainly not useful today :)
    – Navin
    Commented Dec 24, 2014 at 6:55
  • To clarify, this is just about a network firewall rule, not an individual machine's? I would imagine only allowing 80/443 (and maybe 22) would be a lazy, but effective, way to prevent any accidental remote DB or other service access if needed.
    – Nick T
    Commented Dec 24, 2014 at 21:34
  • 1
    When did blocking everything become "standard fare". IMHO most security minded orgs don't care about the ports, but care about where they are connecting and what data the packets contain.
    – Jim B
    Commented Dec 26, 2014 at 4:36
  • 5
    What direction are we blocking here? Is this a firewall with servers behind it, or a firewall with office workers behind it? You mention apps and web browsers, so I guess you are talking about the second case?
    – Jan Fabry
    Commented Dec 26, 2014 at 9:55

4 Answers 4

Reset to default
29

Blocking all ports except 80 and 443 can be part of a good defense in depth strategy. If it is your only strategy then you are correct, it will be a flawed one.

A potential exampled layered approach may be

  1. Block all ports at the external firewall minus 80/443
  2. Have an inline IPS (or as part of your firewall) do packet analysis
  3. Sanitize web-app input with a web application firewall
  4. Sanitize db input with a db firewall
  5. Log everything and feed it into a log management system (with alerts)
  6. Backups on everything (whatever your availability strategy may be)
  7. Harden every OS according to whatever baseline/benchmarks you choose (e.g. Org SOP, CIS/DISA STIGS etc)

This is just one very simple example. A good defense in depth strategy has many layers that together build a secure system.

Improve this answer
10
  • 10
    8. Don't have apps that can't run without other ports being open.
    – corsiKa
    Commented Dec 23, 2014 at 22:24
  • 9
    Even better: block 80 and 443 too. Force web-based applications to use a proxy server in your DMZ. This breaks everything which uses these ports for anything except http and makes it easy to have complex filter rules for anything which does.
    – Philipp
    Commented Dec 23, 2014 at 23:22
  • 2
    @FiascoLabs None of those protocols are publicly accessible unless the client initiated the connection or a port was forwarded. Blocking ports does not fix either issue.
    – Navin
    Commented Dec 24, 2014 at 6:57
  • 6
    @Philipp: And it will brake HTTP/2 (as that is always encrypted).
    – Martin Schröder
    Commented Dec 25, 2014 at 21:15
  • 5
    This post is full of nonsense I don't see why it gets so many upvotes. You say what is good but you don't say why. There is literally no point in blocking outgoing ports, any of them. Only reason corps do that is lame attempt to block old school botnets. Nowadays botnets work over 443 so it doesn't help, it just cripple other software and make whole networking less efficient and transparent as everything needs to be somehow tunneled through one port. Usually people even open VPN through 443 to bypass this stupid firewall rule, it only adds overhead and helps exactly nothing.
    – Petr
    Commented Oct 12, 2016 at 21:46
26

You're absolutely correct. There's nothing magical about port 80, or port 443. There's nothing inherently secure about one port or another, or even one protocol or another. If you block everything but HTTP, everyone will simply start using HTTP. The attackers can and do always move faster than everything else. They aren't limited by maintaining old infrastructure.

In essence, protocols and ports aren't secure or insecure. Blocking them is just another form of security theatre.

Improve this answer
1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop ♦
    Commented Mar 28, 2017 at 19:33
12

White-listing is generally preferable to black-listing. If you only open the ports you actually need, and if you limit those ports to the extent possible, then you've reduced your attack surface area and limited the traffic that you need to watch.

Yes, 80 and 443 can still be abused for malicious traffic. But, you're also raising the bar for attacks (at least a small bit) by forcing them through a much smaller window, and one that you can more easily keep an eye on.

Improve this answer
8
  • networkengineering.stackexchange.com/a/1996 seems to indicate that a better approach would be just ignoring ports altogether and checking for protocol... Users would then be able to actually use various network facilities without being blocked. Is my understanding incorrect?
    – Milind R
    Commented Dec 23, 2014 at 19:18
  • 5
    @MilindR That's at the host-level, which is an entirely different ball of wax from monitoring network ingress/egress.
    – Xander
    Commented Dec 23, 2014 at 19:21
  • 1
    @Xander What is different about the ports 80 and 443? They can also be used for anything – keeping an eye on all ports should not be harder than keeping an eye on 80 and 443…
    – heinrich5991
    Commented Dec 24, 2014 at 11:29
  • 1
    @Xander But why can you keep an eye on 80 and 443 more easily than simply on all ports?
    – heinrich5991
    Commented Dec 24, 2014 at 15:31
  • 1
    @heinrich5991 If you limit the ports to 80 and 443, you're setting the expectation that only the http and https protocols will be supported, so you can run an application-level firewall on those ports. Yes, someone can run ssh on port 443, but they can't really complain when the app-level firewall rejects connections with protocol errors. It's still possible to tunnel things over http/https, but at least it's forced into a protocol your app-layer firewall knows how to inspect.
    – Gordon Davisson
    Commented Dec 24, 2014 at 16:52
3

Port numbers don't matter. The applications that are listening or connecting on any port does matter. Use networking to limit application attack vectors.

Some suggestions:

  • Application nodes should be accessible on multiple networks with different purposes and traffic profiles : an application network and a management network.
  • Avoid applications on ports < 1024, e.g. use 8080 or some other random port. NAT to application ports at application network boundaries (at the LB).
  • Use iptables to only allow application traffic (80, 443) from specific load-balancer IPs (if you're not using direct-route LB) or to internal services (your DB).
  • Limit SSH (22) and other traffic (logging) to a management network.
  • Physically segregate networks, if possible.
  • Don't rely on DNS for application node configuration.
  • Segregate corporate and development networks from production networks.
  • Monitor segregated networks for unapproved traffic. e.g.: SSH traffic on your application network indicates a problem.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .