5 ms·
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 whitelistin
by 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 agoWell, 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 agoThat'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 agoExcept 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.