4 ms·

> No open port = no hacking attempts. That's just obviously nonsense? Closing the port does not change anything about the attempts. Nor about the success rate

> No open port = no hacking attempts. That's just obviously nonsense? Closing the port does not change anything about the attempts. Nor about the success rate of the attempts, if you aren't being an idiot with insecure passwords.

kdelok 8y ago
I think the person above was maybe being too imprecise with their language. Obviously it doesn't affect the frequency of portscans and the like, but whitelisting ports is a reasonable approach to further mitigating your risks.
- zAy0LfpBZLC8mAC 8y ago
  Well, potentially. But then, there is no fundamental difference between a service rejecting unauthorized connections and a firewall rejecting unauthorized connections. If your service is already rejecting unauthorized connections, you don't gain anything by also rejecting the same connections at the firewall, and that is why "No open port = no hacking attempts" is ultimately nonsense: It doesn't change anything about the attempts, and chances are it doesn't fundamentally change anything about the rejections either. Also, adding a VPN exposes the VPN service to the internet, which thus adds attack surface in a different place. Which might be worth it if you need remote access to otherwise vulnerable services. But the simplistic view of "rejecting connections at the firewall" == "no more hacking attempts!11" is just that: simplistic.
  - fgonzag 8y ago
    That's not how it works. If a vulnerability is found in the service, and you don't need external access, blocking it from the firewall/router essentially blocks the vulnerability. In your scenario, with a public facing service, you will get exploited by a 0 day.
    - zAy0LfpBZLC8mAC 8y ago
      Except that a VPN endpoint is a public facing service, which might get exploited with a 0-day. And that "internal services" more often than not are reachable via HTML email or just web browsers on the inside, which might be used to exploit your "internal service" with a 0-day.
fencepost 8y ago
Closing the port does not change anything about the attempts. Nor about the success rate of the attempts, if you aren't being an idiot with insecure passwords. How about "No open port = no concern about possibly vulnerable services running on open ports"? I actually worry less about passwords and more about overflows, protocol problems and parse errors these days.
- zAy0LfpBZLC8mAC 8y ago
  Yeah, sure, but (a) then those problems potentially also affect the VPN endpoint, so it's still a trade-off (b) much of the complex protocol machinery often is behind the authentication barrier, so the risk of just exposing the port to the public isn't necessarily that big, and (c) a firewall doesn't necessarily protect your vulnerable service, often there are browsers on the inside that an attacker could use to access those "protected" services. My point isn't that blocking off ports at the firewall is always pointless, but that it's usually a trade-off, and keeping a vulnerable service running behind the firewall can still be a risk, and many "hacking attempts" are just irrelevant if you follow general best security practices, so it's pointless to do anything specifically to prevent them.

kdelok 8y ago

I think the person above was maybe being too imprecise with their language. Obviously it doesn't affect the frequency of portscans and the like, but whitelisting ports is a reasonable approach to further mitigating your risks.

zAy0LfpBZLC8mAC 8y ago
Well, potentially. But then, there is no fundamental difference between a service rejecting unauthorized connections and a firewall rejecting unauthorized connections. If your service is already rejecting unauthorized connections, you don't gain anything by also rejecting the same connections at the firewall, and that is why "No open port = no hacking attempts" is ultimately nonsense: It doesn't change anything about the attempts, and chances are it doesn't fundamentally change anything about the rejections either. Also, adding a VPN exposes the VPN service to the internet, which thus adds attack surface in a different place. Which might be worth it if you need remote access to otherwise vulnerable services. But the simplistic view of "rejecting connections at the firewall" == "no more hacking attempts!11" is just that: simplistic.
- fgonzag 8y ago
  That's not how it works. If a vulnerability is found in the service, and you don't need external access, blocking it from the firewall/router essentially blocks the vulnerability. In your scenario, with a public facing service, you will get exploited by a 0 day.
  - zAy0LfpBZLC8mAC 8y ago
    Except that a VPN endpoint is a public facing service, which might get exploited with a 0-day. And that "internal services" more often than not are reachable via HTML email or just web browsers on the inside, which might be used to exploit your "internal service" with a 0-day.

fencepost 8y ago

Closing the port does not change anything about the attempts. Nor about the success rate of the attempts, if you aren't being an idiot with insecure passwords. How about "No open port = no concern about possibly vulnerable services running on open ports"? I actually worry less about passwords and more about overflows, protocol problems and parse errors these days.

zAy0LfpBZLC8mAC 8y ago
Yeah, sure, but (a) then those problems potentially also affect the VPN endpoint, so it's still a trade-off (b) much of the complex protocol machinery often is behind the authentication barrier, so the risk of just exposing the port to the public isn't necessarily that big, and (c) a firewall doesn't necessarily protect your vulnerable service, often there are browsers on the inside that an attacker could use to access those "protected" services. My point isn't that blocking off ports at the firewall is always pointless, but that it's usually a trade-off, and keeping a vulnerable service running behind the firewall can still be a risk, and many "hacking attempts" are just irrelevant if you follow general best security practices, so it's pointless to do anything specifically to prevent them.