Architecture for securing home network with exposed web server
-
What you could do is move pfSense so it's connected directly to the ISP router and everything else is behind it. Then you can device you internal hosts between two pfSense interfaces in the normal way.
Your ISP router may have a pass-through or DMZ made where is just passes all traffic to pfSense that could be used there.
-
thanks guys!
Physically I think I have problem putting pfSense right after the ISP router and behind everything else (if I understood correctly the setup you meant)
I did try however something now in the firewall rules as you suggested.
I will sum up the setup and the firewall rules:
In Hyper-V, I have 2 virtual switches - a WAN and a private LAN.
Both switches are connected to the pfSense VM.
the LAN switch is acting as a DHCP and connected to the Ubuntu Server VM (the web server)Now, I just added a blocking rule for any IP and any protocol from the LAN to the WAN subnets:
(*Note that the IPs are different than above comments as I've changed stuff)Image of the setup on the pfSense VM:
Image of the FW rule:
Now I tried to access my router's management IP on 192.168.2.1 and I could not do it anymore, and I can no longer ping any machine on the 192.168.2.1/24 range (the home network). Does it mean I actually isolated the VM?
-
Well that rule has isolated it from everything! All traffic is blocked except to the OPTX address on port 80.
Your block rule should be: source: OPTXnet, destination: WANnet.
Then you should have a pass rule below that for other destinations outside the WAN.
-
@stephenw10 thank you!
In Cloudflare, I set the service to be HTTP (port 80) and the OPTx IPv4 address - exactly the one that is open, and I am able to visit my domain at https://example.com - I can to go to the HTTPS because Cloudflare redirects HTTPS to the internal HTTP
I am still able to go to the machine via Hyper-V which is what I need to perform manual git updates
Should that be enough? Why would I need the rule you suggested over the current rule (for knowledge, not to say that your rule isn't good
) - what does it allow that currently isn't allowed - could you please provide examples?Maybe you mean that I can't SSH to the machine (which I don't need right now but might need soon)? Or something else that I haven't encountered yet?
-
It would allow the VM to connect out, to pull updates for example. If it doesn't need to do that then you don't need any other rule.
-
@stephenw10 thank you, got it. didn't think about updates, so I will do what you said.
But, someone told me that even with what I did now, it's still not really isolated, because traffic still must go through the home router. So even if the only open port is 80 for the web, and even if my VM is on a different IP range, the initial traffic must still go through the router.
I am curious now because it does seem true - but I don't have cyber security knowledge to know what attackers today are capable of
What do you think - is there a way a hacker can go through the tunnel (through the open port 80 on the 172.16.20.1/24 IP range), and somehow instead of going straight from the router to the VM, it will stop at the router, and escape to the home network?
This is a drawing of what I see in my head:
-
Unlikely.
More likely would be they find some exploit with the ISP router and can connect to that directly. From there they could access anything on your network. That would have nothing to do wit the port 80 forward though.
Or they find some exploit in the web server VM and gain access to that. The VM has no outbound access though it wouldn't help them much.
But, yes, it's not real isolation because the traffic to the VM is routed across the LAN. They should really be separated at the edge router/firewall.
-
@stephenw10 thank you!
When you said it has nothing to do with port 80 - then how? Just because of the tunnel itself?
-
Nope just because ISP supplied routers regularly see exploits if they are not updated. If you have added a port forward to it that's a config the vast majority of users likely don't use so that may expose something there potentially. It's a relatively low risk IMO.
-
@stephenw10 oh, so that risk would only happen if i forwarded a port on my isp router? Because I didn't
In order to use my web server I'm using a cloudflare tunnel which doesn't require any port forwarding
-
Some level of increased risk yes.
How is the tunnel connected? Something is connecting out to Clouflare I assume. But not from the VM since the firewall rules you have prevent that.
-
@stephenw10 It really is weird now that you say that.
Because the only open port is 80. Could that be done through port 80?
Because in Cloudflare I only set the IP of the Ubuntu VM and nothing else, on port 80:
172.16.20.100:80
Is Cloudflare tunnel based on Wireguard? If so, could it be that the initial handshake to the Cloudflare tunnel was done before I created the firewall rules, and that was able to do that initial handshake? So if for example I now create a new tunnel, I won't be able to get that first handshake?
Or, I have something misconfigured :)
-
I believe it is based on Wireguard, yes. Where are you running the client?
That IP address for the VM is a private address so Cloudfllare would only be able to access it across a tunnel.
Where exactly is port 80 open?
-
@stephenw10 it's the rule in the picture in the above comment where it shows the destination is the OPTX Address and the Port is 80 so I think that's it?
I also checked other things like updating the server (sudo apt-get update) and indeed I cannot update. So if I recall correctly, WireGuard only needs the first handshake with the peer and then it sends keep alive pings all the time.
I can do a test and create a new tunnel to see if this is really it
-
That's the anti-lockout rule. It added by pfSense to allow hosts, on what would normally be the LAN, to always have access to the pfSense webgui.
It would not allow the VM to connect too Cloudflare. Nor Couldflre to connect to the VM. -
When you say connect to the tunnel, you mean the peer handshake? For example, if the initial connection was done on port 51820 - this is what you mean by not allow the connection?
-
Yes. The rule you have there would block all outbound traffic from the VM to cloudflare.
It's possible it had already connected before you added the rule in which case the connection would remain until the state is lost at reboot for example.
-
It's so weird (and annoying). Everything was working, and then I removed the firewall rule, so actually opened everything, and now nothing works - the tunnel stopped working and I can't even ping to the WAN anymore, and can't do sudo apt-get update.
How?! I removed the firewall rule, then how it did the opposite?
Last time it happened, I switched from DNS resolver to DNS forwarder and it started working. But now - the DNS forwarder is still the one enabled. so now I'm lost as to what happened.
Edit: I now created a "pass" rule for Any/Any and I can ping to the WAN again. However, DNS still doesn't work again.
-
Yes you would need a pass rule to allow it.
If it's pass all and any protocol then DNS should work as long as it's configured in the VM correctly.
-
@stephenw10 said in Architecture for securing home network with exposed web server:
Yes you would need a pass rule to allow it.
If it's pass all and any protocol then DNS should work as long as it's configured in the VM correctly.
thank you.
I am curious though now regarding the previous discussion - so in the case where I closed all ports earlier (after the handshake), and then only port 80 was open.
So surfing the website on my domain was possible according my theory. But, the HTTP request needs a response - and the response needs to go out from the server to the world via port 80. But the Anti-Lockout rule is only from source (*) and destination OPTX address. but not opposite - so how did the response go back out to whoever go to the domain? Or, it all happens in the same connection - request in port 80 - response goes back in this connection?
