Risks of exposing one port to WAN

[jimjohn]

Hi,

I got kind of a philosophical question. Currently, I am running a router cascade (Fritz.Box + OPNsense Appliance behind it).

I am using the Fritz.Box' VPN (IPsec) currently for site-to-site as well as for mobile client access. The problem now is that Apple's mobile devices do not allow a persistent IPsec tunnel. Hence, I want to use either OpenVPN or Wireguard along with the respective applications that allow me to do exactly that. I now wonder what could happen if I forward the OpenVPN / Wireguard port of the Fritz.Box to the OPNsense WAN. Obviously, I only want to open this one respective port. What is generally the risk of opening ports?

Assuming I use Wireguard for my mobile clients, what are the attack scenarios / vectors which are added to my current setup (since the Fritz.Box uses IPsec, it must have opened UDP 4500 and 500)?

[bartjsmit]

Any port that is open to the world is part of your attack surface and any service that listens on a port needs to be kept updated. I would suspect that a consumer device such as Fritz!Box receives updates less frequently than a software based VPN endpoint such as OPNsense.

You therefore maximise security by disabling the IPSec and forwarding a single port to your internal VPN server.

Bart...

[jimjohn]

Hi Bart,

thanks for your answer. I get your point with the update frequency.

You are saying that only bugs in the service that blocks the port can be used to attack, correct? No other vulnerabilities or attack strategies you can think of?

I would only allow traffic from VPN to WAN I think so that no other device in the LAN can be accessed from outside (I only want to secure traffic while being on the road by piping it through a VPN tunnel).

I get your point on the update frequency of the Fritz.Box vs. OPNsense. Good thought!

Are there any mechanisms to harden that VPN? E.g. wrong logins deactivate the service for - let's say - 6h and send a mail to me?

Any other ideas to harden my setup?

[bartjsmit]

You are saying that only bugs in the service that blocks the port can be used to attack, correct? No other vulnerabilities or attack strategies you can think of?

If you exclude physical security e.g. evil maid (or butler, let's not be sexist) then you are left with vulnerabilities in the protocol itself, or software bugs in the implementation. Nobody writes monolithic software from scratch anymore, so there are also supply chain attacks on the software side - in this case Open/LibreSSL is the obvious concern. Remember that crypto is hard and a peer reviewed and heavily scrutinised library is essential. Bruce Schneier said it best: https://www.schneier.com/crypto-gram/archives/1998/1015.html#cipherdesign

In that vein, OpenVPN is a more mature than WireGuard but that is no guarantee for fewer bugs.

wrong logins deactivate the service for - let's say - 6h and send a mail to me?

That opens you up to denial of service. I rent a botnet to hammer your service with logins for a few seconds and you go dark for hours. Use two factor authentication and attackers won't even get a chance to try wrong logins. OpenVPN can use a static key as a bare minimum. TOTP is much better but less trivial to configure. https://docs.opnsense.org/manual/how-tos/two_factor.html

Send your logs to an analysis stack inside your network, something like Splunk or ELK and get that to alert you about anomalies. You can look forward to a long time of fine tuning though. Every environment is different.

You're on the right track for hardening by limiting your open ports. The fewer functions your firewall performs, the lower the chance that one of them has a bug. Move your DNS, DHCP, proxies (e.g. Squid) to servers inside the firewall. Have a look at RADIUS if you have an existing user directory for authentication. That mitigates against privilege elevation on the firewall itself. https://docs.opnsense.org/manual/how-tos/user-radius.html

Years ago I worked on firewalls that even incremented the packet TTL field so they wouldn't show up in traceroute - literally acting like a hole in the network but that was for larger setups that basically didn't trust internal users. Security policy is a fine line between risk reduction and usability.

Bart...

[jimjohn]

Thanks for your extensive answer, very appreciated.

I have a few questions:

DoS attacks: it's a private system with 5-6 users at maximum. I do not care too much if the service goes down. It is more important for me that the data behind is secure. Do you think that is a problem in that case?

Outsourcing services: Currently, DNS, DHCP, etc. is running on the OPNsense appliance. Why would you put it on another appliance? I have a Proxmox host that I could use. Can you elaborate on the advantages on the security side?

TOTP: Can OpenVPN use TOTP for login? Or are you talking about the login of the OPNsense's web GUI? The latter I would not allow from the VPN connections I think.

Evil maid / butler: Let's exclude that case for that particular question.

Logging / Monitoring: Why didn't you propose Zabbix or monit? Never heard of the applications you mentioned. :-)

[bartjsmit]

DoS attacks: it's a private system with 5-6 users at maximum. I do not care too much if the service goes down. It is more important for me that the data behind is secure. Do you think that is a problem in that case?

The availability issue is not the main one in your use case. A higher risk is that one of your users falls prey to social engineering or re-uses a password that has been compromised as part of an attack on another service. Passwords are a poor security concept - MFA is far superior.

Outsourcing services: Currently, DNS, DHCP, etc. is running on the OPNsense appliance. Why would you put it on another appliance? I have a Proxmox host that I could use. Can you elaborate on the advantages on the security side?

The OpenVPN service in OPNsense is let's say 1000 lines of code. Unbound, Squid, DHCP represent 4000 lines for argument's sake. The chance of a bug affecting a system running all four services is much higher than one running just one. Granted, only your VPN is open to the internet, but more services means more running daemons and more complexity. Simplicity aids security since there are fewer parameters that affect your firewall.

TOTP: Can OpenVPN use TOTP for login? Or are you talking about the login of the OPNsense's web GUI? The latter I would not allow from the VPN connections I think.

Yes TOTP is available for all OPNsense services, including VPN. You are right about restricting access to your GUI.

Logging / Monitoring: Why didn't you propose Zabbix or monit? Never heard of the applicaions you mentioned. :-)

Monitoring is wider than log analysis. Zabbix, Nagios, Monit are general applications that do include inputs from logs. Splunk and Elastic are more specialist tools. From a more fundamental viewpoint the important thing is that you keep your logs outside the asset being managed, making it harder for a successful attacker to erase their tracks.

Bart...