7

It seems that the status quo at the moment is to configure firewalls to drop any packets that aren't destined for specifically-opened ports. Many defensive port scanners (such as ShieldsUP!) seem to praise you for every port that has a DROP policy. If you were to port-scan any of the top domains in the world, almost all of them would show that their default policy is DROP except on needed ports such as 80 and 443.

What is the mentality behind this? It can't be for stealth, because if ports 80 and 443 respond then it would be extremely trivial to see that the host is up. It can't be for defense against SYN floods either, since you could just direct the packets to the ports that ARE open. The only thing that I can think of is that there are other services running on the outward-facing interface, but instead of taking the time to properly configure these services, admins just throw a firewall in front of it. Still, one would think that the top websites in the world would have their act together enough to properly configure their servers.

Am I missing something here? Does setting a default DROP policy really do anything to improve security on a properly configured server?

Edit:

I just want to clarify my question a bit. What I don't understand is why people feel a need to put a layer up that drops packets instead of letting them through and letting the networking stack do its job. (Putting up a layer that responds artificially with RSTs would be essentially the same thing and it raises the same questions.)

I'm not trying to imply that a firewall is useless, but it seems as though people don't trust the networking stack to the point that they forbid direct contact with it except on allowed ports. What is the real harm in exposing it and interfering with it as little as possible?

Improve this question
5
  • 1
    It's not clear what you are asking. Are you asking whether DROP is better than REJECT? Whether DROP is better than ACCEPT? Something else? Basically, tell us what the alternative that you want us to compare to. "improves" is inherently relative, but you haven't told us what baseline you want to compare to. I suggest editing the question to clarify explicitly. Also, don't just append "Edit: some other stuff" to the end of your question. We have revision history, so you don't need to do that -- rewrite your question to be what it should have been from the start.
    – D.W.
    Commented Jul 23, 2015 at 23:44
  • @D.W. Well, yes and no. Generally speaking, you don't write "Edit" on a post to make up for a lack of versioning; you do it because you can't expect all users reading the question to look through the entire revision history, so if they see an answer that says something along the lines of "Not sure what you're asking, but...", they might be inclined to comment on that answer with something like "No, that's clearly not what was asked". It's actually a courtesy to those who answered before the edit.
    – Parthian Shot
    Commented Jul 24, 2015 at 0:21
  • @D.W. However, I suppose an easy workaround would be to completely rewrite the question and simply make some reference to "this was edited, and it was way less clear before" at the end.
    – Parthian Shot
    Commented Jul 24, 2015 at 0:22
  • 1
    @ParthianShot, I realize that's what some people might be thinking, but nonetheless, on this site, we discourage use of "Stuff. Edit: More stuff." A large part of our mission is to build an archive of high-quality questions and answers that will be useful to future readers; "Edit: blah" is a bad pattern. See meta.stackexchange.com/q/127639/160917 and meta.stackexchange.com/q/202472/160917 and meta.stackexchange.com/q/183267/160917 for extensive discussion and reasons why you probably shouldn't use "Edit:" like that.
    – D.W.
    Commented Jul 24, 2015 at 0:28
  • @D.W. +1 because sources. I'd also like to point out that my solution, of fixing the question and adding a note at the bottom to mention the change, is the one suggested in the top-voted answer to the second question linked. It makes sense because it prevents users whose answers were good at the time from being downvoted to oblivion after the edit.
    – Parthian Shot
    Commented Jul 24, 2015 at 0:42

5 Answers 5

Reset to default
4

Employing a default DROP rule for all ports except the ones originally intended(for a website these are 80/443) reduces the attack surface of the given stations on the network. It's much more convenient(and cheaper) to drop packets instead of configuring a service so that it is secure with regards to a given policy.

Improve this answer
5
  • You're saying that, basically it makes it harder to do something stupid if you set everything to drop-by-default?
    – Mike Ounsworth
    Commented Jul 23, 2015 at 19:56
  • Yes. Even though nowadays software packages are mature(they don't ship with default credentials) there are still risks due to improper choice of credentials(many users pick an easily guessable password).
    – Sebi
    Commented Jul 23, 2015 at 20:35
  • I think it makes it easier to do something stupid due to the tendency to think, "oh well the firewall will stop it." Like I said elsewhere, a competent network professional shouldn't break a sweat from setting up a server's daemons with proper configuration.
    – hololeap
    Commented Jul 23, 2015 at 21:14
  • @hololeap "a competent network professional shouldn't break a sweat from setting up a server's daemons with proper configuration." ...But as I mentioned in my answer, the network professional can't account for 0days in those services, while an attacker can. And if the "network professional" isn't a complete charlatan, they'll be whitelisting IPs and setting up SPA where possible, to markedly decrease the attack surface on apps with a smaller audience.
    – Parthian Shot
    Commented Jul 24, 2015 at 6:48
  • @hololeap Besides which, most enterprise applications (sometimes even for security or compliance reasons) may not be able to simply update whatever service to the most recent version, even if it has known bugs, because the new configuration would need to be adequately tested and qualified by QA. In which case, you'll want to limit that service's exposure to the outside world.
    – Parthian Shot
    Commented Jul 24, 2015 at 6:50
2

I would put it down to defence in depth. Yes, you could configure your services to listen to only localhost or your internal network. Even when properly configured, there is still a possibility that due to a bug in the code, it mistakenly accepts all traffic. Services which accept UDP packets may also be vulnerable to an IP spoofing attack. TCP is resistant to such an attack since the connection setup never takes place, but you may end up with many half open TCP connections, which may DOS your service. This can be carried out because the attacker can spoof an internal IP address which is allowed to access the service. This attack is commonly known as a SYN flood attack. More info: http://searchsecurity.techtarget.com/definition/SYN-flooding

At the end of the day, having extra precautions increases the amount of work an attacker has to do to compromise your system. Additional safegaurds also reduces the chance of a single mistake causing a breach.

Improve this answer
5
  • I just hope that admins don't use this extra safeguard as an excuse to be lazy or use buggy software. I mean, any competent network professional should know how to configure sensitive services so that they aren't listening on the outside interface.
    – hololeap
    Commented Jul 23, 2015 at 21:00
  • Also, I would think that any open TCP port would be vulnerable to the type of DOS you are describing, regardless of whether other ports respond with a RST or just drop the packet.
    – hololeap
    Commented Jul 23, 2015 at 21:04
  • Unfortunately, nobody knows if software is buggy. Look at heartbleed, shellshock... OpenSSL and Bash are examples of software that are everywhere. Almost every Linux server uses them, bugs are found years after.
    – limbenjamin
    Commented Jul 23, 2015 at 21:05
  • More information on SYN flood attack, which I was describing. searchsecurity.techtarget.com/definition/SYN-flooding
    – limbenjamin
    Commented Jul 23, 2015 at 21:06
  • I agree that software can be buggy, but the type of bug we are talking about, where a service listens on all interfaces by mistake, seems very unlikely. Most scary bugs affect the software on open ports. Also, why would a server that responds on port 80 but has DROP on all other ports be any less vulnerable to a SYN flood? TCP uses a three-way handshake for both open and closed ports.
    – hololeap
    Commented Jul 23, 2015 at 22:01
1

There's a couple of different spins that can be put on your question, but I'm going to address Is it better to DROP for non-allowed ports than to REJECT?

Dropping packets - silently, no TCP RST or ICMP Prohibited - is preferable for at least two reasons.

  1. It slows down scanners that are trying to hit a large number of your ports, because they don't get positive feedback.
  2. It reduces false positives on scans - scanners that see RST/Prohibited messages come to expect them, and when doing a large scan sometimes these packets get lost. If you never send responses then they don't miss dropped packets on a scan, and it shuts them up.

If you're a scanning yourself (e.g. for compliance checking) reducing those false positives is a noticeable improvement. And if you're lowering false positives for malicious scanners, well, I'd rather they not get excited to come looking at ports that are actually closed; I'd rather they have an accurate scan and, looking at it, decide to go fishing elsewhere.

Improve this answer
2
  • I don't think that slowing down port scans is a good reason to DROP by default. Slowing a port scan down from 5 minutes to an hour isn't going to matter much for an attacker. Also, good port scanners will retry a port several times to see if a port is configured to DROP or if the packet was simply lost in transit.
    – hololeap
    Commented Jul 23, 2015 at 21:11
  • 2
    In my experience pentesting /24s on the Internet it's not "5 minutes to an hour" it's "days to weeks". I agree that in a technical sense there's always enough time to scan either way, but humans are not the most patient of beasts.
    – gowenfawr
    Commented Jul 23, 2015 at 22:44
1

You understand the situation correctly; there is minimal benefit in dropping traffic to closed ports. However, it is still considered "best practice".

I think the reason ShieldsUP would report this is that is could indicate a configuration error. If a firewall admin intends to block all the closed ports, and misses one for some reason, this is something ShieldsUP can detect in a scan. Did they put a risk rating on the finding? If it's anything higher than "low" then I'd seriously question that.

Network firewall technology has not changed much since the late 90s, and a lot of advice comes from an era of "more lockdown is good" without great understanding of what lockdowns actually help. Most of the progress that has happened with firewalls is moving beyond the network layer and doing "deep inspection". But on a closed port, there's absolutely no deep inspection to be done.

Improve this answer
1

Off the top of my head, one obvious reason is that it forces the scanner to take longer to determine whether a service is present on a given port or not. It doesn't know whether packets were dropped on the path, or the path to the server it's accessing just has a long RTT, or there's a default DROP firewall policy. And anything that slows down attackers, and only mildly inconveniences people mapping the internet, without affecting legitimate users you actually want to connect, is a Good Thing(TM).

Then there's the fact that this statement on your part "instead of taking the time to properly configure these services, admins just throw a firewall in front of it." fails to account for the fact that these services may be as properly configured as possible, and still contain an 0day. You may want the service to be running- and even visible to (some) external users- but hidden behind a port knocking / SPA solution, or simply filtering by IP address (by putting in a rule which accepts TCP attempts from whitelisted addresses).

If you're using SPA, it doesn't matter how many services are behind the firewall, or how many of them have horrible misconfigurations or 0days, the only ones you need to worry about are the firewall itself, the SPA solution, and the services explicitly whitelisted in the firewall. Of course, you also need to worry about who has SPA keys, but that's a different discussion.

And if you filter by IP, it's the same idea; except now you just need to trust those hosts, trust the firewall, trust your ISP (to a degree), and trust that a single stray, spoofed packet alone won't be able to break the service.

This makes sense for the same reason all whitelisting makes sense; security is never harmed, and usually aided, when capabilities are dispensed on a strictly need-to-have basis, and information is dispensed on a need-to-know basis.

For the OUTPUT and FORWARDING chains, the reasoning behind a default DROP policy should be pretty obvious; default DROP policies on those chains are the most fundamental part of any egress filtering policy.

Improve this answer

You must log in to answer this question.

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