Architecture for securing home network with exposed web server
-
@SteveITS said in Architecture for securing home network with exposed web server:
@forumate said in Architecture for securing home network with exposed web server:
I did create a network with different IP range, isn't it considered a VLAN?
No, not that alone. A VLAN is a separate network but sharing the same cabling, and most importantly isolated by the switch. So multiple networks would share one patch cable into pfSense but be isolated by the switch. Each packet is tagged (usually by the switch, or AP) as to which VLAN it is for.
https://docs.netgate.com/pfsense/en/latest/vlan/index.htmlAfter setup a VLAN in pfSense is basically the same as a third, fourth, etc. interface. Firewall rules control access between networks in pfSense.
If the two subnets are not isolated then you run into trouble with things like DHCP, plus all someone has to do is change their IP to hop onto the other network.
thank you, I will have to read more about the VLAN then.
@stephenw10 said in Architecture for securing home network with exposed web server:
@SteveITS said in Architecture for securing home network with exposed web server:
For sake of discussion, which?
It may not be mentioned specifically there but I worried there might be links to the 1100 switch setup that wouldn't apply here.
@forumate Because you are using a virtual infrastructure you don't need to use VLANs here. You can just add more virtual NICs and switches if you want additional subnets behind pfSense.
You can add firewall rules on the LAN to prevent LAN side hosts accessing the WAN side hosts directly. However that's not a good setup because the traffic from the LAN side hosts (DMZ) still has to travel across the WAN where all the protected clients should be.
What you want to have are LAN and DMZ interfaces in pfSense where traffic is completely separate and any connections between them must go through pfSense and hence can be filtered.Steve
I am new to networking. When you say DMZ, what way of DMZ setup do you mean? by usin VLANs as suggested above?
-
No just mean a different subnet connected via an interface named DMZ. It could also be named OPT etc. The nature of a DMZ is simply what traffic is allowed in and out of it. So here it's just what firewall rules you have applied to that traffic.
-
@stephenw10 thank you.
Currently I have WAN and LAN called OPTx.
You say I should add another virtual private LAN switch on hyper-v, connect it in pfsense as a LAN interface as well, call it DMZ for example and connect it to the OPTx?
So that I'll have 3 subnets?
192.168.2.1/24 of the home network
172.15.100.1/24 - OPTx
10.0.0.1/24 as DMZthen separate the DMZ from the home network by having the OPTx in between?
-
@forumate I think you’re getting hung up on the names. The names are irrelevant. WAN and LAN are pretty standard. You can name others however you wish. If DMZ is easier to understand conceptually, go for that. Then you have 3 interfaces, and a web server in DMZ is not on LAN.
-
Your setup is different currently because pfSense is not your edge router. Currently all traffic has to travel across your local LAN to reach pfSense and any hosts behind it. There is no need to add an extra interface in your setup as it is.
You can still add firewall rules to prevent hosts behind pfSense accessing the local LAN devices directly. -
@SteveITS said in Architecture for securing home network with exposed web server:
@forumate I think you’re getting hung up on the names. The names are irrelevant. WAN and LAN are pretty standard. You can name others however you wish. If DMZ is easier to understand conceptually, go for that. Then you have 3 interfaces, and a web server in DMZ is not on LAN.
Oh I just gave names in this case for the example, I understand that names are not important (just because I wanted to make the example more understandable)
What do you mean a web server in DMZ is not on LAN?
@stephenw10 said in Architecture for securing home network with exposed web server:
Your setup is different currently because pfSense is not your edge router. Currently all traffic has to travel across your local LAN to reach pfSense and any hosts behind it. There is no need to add an extra interface in your setup as it is.
You can still add firewall rules to prevent hosts behind pfSense accessing the local LAN devices directly.Yes exactly there is a problem because I must use the ISP router right now as the edge router. So I thought to use pfSense with firewall rules as you said.
So because it has to go through the ISP router, as you said I can just have 2 interfaces?
- The private WAN switch
- The private LAN switch - and give it different IP range, and firewall rules to not be able to access anything else outside its IP range?
How can I do it? Could you give me hints where to start?
And is it even possible to have a firewall rule that will prevent access to my edge router, and still keep the private LAN interface connected to the internet? Is it sort of like a one-way valve? where traffic can come from the ISP 10.0.0.138 to the pfSense VM on 192.168.2.1 (for example), but not the other way around? Is this the general idea? (I just want to understand the theory too before I actually set firewall rules)
-
@forumate said in Architecture for securing home network with exposed web server:
What do you mean a web server in DMZ is not on LAN?
A DMZ type network is a separate network from LAN so compromised devices cannot infect LAN devices.
https://en.wikipedia.org/wiki/DMZ_(computing)
Usually via separate wiring or a true VLAN. A "guest wireless" would be another example.Each interface in pfSense can have its own rules, for instance a guest/DMZ could have something like:
- allow to pfSense DNS
- reject to This Firewall
- reject to LAN
- allow to any
one such example: https://docs.netgate.com/pfsense/en/latest/solutions/netgate-4100/opt-lan.html#isolated
Rereading your OP, I think I misunderstood. If you simply put pfSense between your web server and your LAN, and do nothing else, that would not prevent your web server from accessing your LAN (pfSense's WAN). Because pfSense would NAT requests onto your LAN just like it does to the Internet. You would need to block access by firewall rules.
-
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?
