34

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?

  • 5
    Yes it is a quite stupid approach, it doesnt work against bad guys. – Uwe Burger Dec 23 '14 at 18:45
  • 8
    today!? It wasn't useful yesterday and it's certainly not useful today :) – Navin Dec 24 '14 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 Dec 24 '14 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 Dec 26 '14 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 Dec 26 '14 at 9:55
32

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.

  • 10
    8. Don't have apps that can't run without other ports being open. – corsiKa Dec 23 '14 at 22:24
  • 8
    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 Dec 23 '14 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 Dec 24 '14 at 6:57
  • 5
    @Philipp: And it will brake HTTP/2 (as that is always encrypted). – Martin Schröder Dec 25 '14 at 21:15
  • 2
    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 Oct 12 '16 at 21:46
23

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.

11

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.

  • 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 Dec 23 '14 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 Dec 23 '14 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 Dec 24 '14 at 11:29
  • @heinrich5991 Nothing is different about them, per se. It's simply that they need to be be open for routine HTTP/HTTPS traffic. – Xander Dec 24 '14 at 13:33
  • 1
    @Xander But why can you keep an eye on 80 and 443 more easily than simply on all ports? – heinrich5991 Dec 24 '14 at 15:31
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.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.