DMZ bridged to WAN cannot reach LAN
-
I do similar stuff as @johnpoz has recommended but can simplify the explanation:
If you have an application that requires access to a data source, put that data source into the DMZ with the app server. Things that need to access that data can always reach into the DMZ to pull things out, by design.
Now the complicated part that usually annoys the heck out of app developers:
For security purposes, the data source inside the DMZ should contain very little data. You can have a LAN-based database replicate or extract any new data at a set interval (1 second, 5 seconds) to move it into the LAN. The concept is application and data segregation over the network. Always assume your exposed server is going to get breached. You should move all important data into the LAN into another part of the application that will poll the servers/services in the DMZ for new data. They will pull data into the LAN where it can be processed and then pushed back into the DMZ, and then the servers/services in the DMZ can send it out the WAN to the client that requested it. This way, when your servers in the DMZ get breached, there is very little data there at all.
Architecting applications like this creates overhead, and you need to take that into account as you architect them. However, the principles are there to protect your data. Once a hacker breaches your stuff, the next thing they will do is pivot to exploit other devices. By caging them in the DMZ, they cannot pivot, or they can only pivot to other servers within the DMZ (or not, depending on how you designed it). If your data source of record is stored in your LAN, there is very little chance that when you do get breached, they won't be able to reach that data.
If I can't design like that and am required to create pinholes, I usually have someone sign off in blood on that. My network is only as secure as your app requirements allow me make it. :)
-
Hi, you give us good and right suggestions....
just to explain...
In my case the (main) purpose is to use a NAS (freenas) in the LAN both as LAN file server (throught smb shares) and as repository for the git server in the DMZ.
The best solution would be one NAS in the DMZ and a second NAS in the LAN that replicates or backups data in the DMZ (with a connection LAN to DMZ).... but we are a small office and we to deal with resources; so i decided to compromise using the same NAS in the LAN also for the DMZ server....
Thx
Alessandro -
So you understand there is risk, yet you choose to expose ALL of your data to the public, not just the git data?
So who signs off on this risk? Is Tim's point ;)
Get another nas for your git data.. Have your nas from your secure network back up the data.. Sorry your normal nas data that users access is now at risk.. Lets say the box is exploited... What keeps them from compromise of the data your users are accessing.
You might be more secure leaving the nas in lan, and only allow pin hole from the git server to the git data that is isolated on its own volume/lun and only access via specific protocol from the git dmz server.. This reduces the protocols that are allowed through the firewall... Vs say http to the git server which would then have unfettered access to the nas since on the same network with no firewall between. If your going to do such a thing then you need to make sure all other protocols disabled or locked down with HOST firewall, etc. etc.. Or you put the nas in the internal dmz vs the external one like I was saying.
-
@lalex86 said in DMZ bridged to WAN cannot reach LAN:
Hi, you give us good and right suggestions....
just to explain...
In my case the (main) purpose is to use a NAS (freenas) in the LAN both as LAN file server (throught smb shares) and as repository for the git server in the DMZ.
The best solution would be one NAS in the DMZ and a second NAS in the LAN that replicates or backups data in the DMZ (with a connection LAN to DMZ).... but we are a small office and we to deal with resources; so i decided to compromise using the same NAS in the LAN also for the DMZ server....
Thx
AlessandroI have a similar requirement at a client's office. Here was my general approach:
Only give specific and limited access to devices that need to do this. So in pfSense you want to only open the ports/protocol necessary to make and maintain a SMB connection to the NAS. I think that's 3 ports. The point that you're mounting on the NAS should only contain the data that the server needs to access. Create a "service login" specifically for that server to use, and limit the access of that login only to the mount point with the data it needs to access.
This way when the server gets breached, the bad actor can only access a SMB mount point that only contains that server's data. It will be very difficult for them to pivot from that point, but it does put your data at risk of corruption from a bad actor. With proper backups in place (and a reasonable RTO/RPO), you can minimize that risk.
-
SMB should run over 1 port tcp 445... No need to open up the the old school netbios ports.
-
@lalex86 yes, you are missed basic's of networking security?
I totally agree with @johnpoz and @stephenw10 write , but if you want explore new ways for make firewall-ing concept to work, I advice you to add , first of all ...more NIC on your server, and reserve one nic for DmZ and other to Lan.
By this way , you can handle connections of any kind , with a proper configuration for each one, meets firewall-ing standard concept in mind.
More nic's more fun! hahah lool
Please forgive me
-
@babiz said in DMZ bridged to WAN cannot reach LAN:
@lalex86 yes, you are missed basic's of networking security?
I totally agree with @johnpoz and @stephenw10 write , but if you want explore new ways for make firewall-ing concept to work, I advice you to add , first of all ...more NIC on your server, and reserve one nic for DmZ and other to Lan.
By this way , you can handle connections of any kind , with a proper configuration for each one, meets firewall-ing standard concept in mind.
More nic's more fun! hahah lool
Please forgive me
Oh, I disagree! Once you breach that one system, since it's on both networks, you now have access to both.
-
@tim-mcmanus You are right!
Anyway my next goal for next weeks is made like pfsense+xpenology virtualized together on linux based host and virtualbox!
I have no idea if this is enough "secure", but I love more nics on my Xeon older E5 bare metal 16 core cpu! ghhh just starting with 16 gb of ram, also I love Xeon motherboard arch. It's for tough server stuff.
Sorry for OT, I'm kiking out. -
Thx all but you are going over what i'm saying and asking :).
You are writing referring to scenarios different from mine....:
- there are 3 (virtual because is all on a Proxmox environment) NICs (wan,lan,dmz)
- NAS is in the LAN
- the LAN contains only some virtual desktops accessed remotly
- the NAS has a share dedicated (with protocol and user credentials) to the host in the DMZ...
- actually all the virtual infrastructure is protected from a VPN and only the SSH port is opened to the DMZ with authentications with certificates...
Anyway the main purpose of this topic was to better understand about pfSense internals and routing.... not about security issues that I known.
Thx
Alessandro -
Moreover ...
Host in DMZ will run a git server and a owncloud server...
Where shoud owncloud files (usually replicas of private data) live?
thx
Alessandro -
I think the main point here is that the best practice is to store only the minimal amount of data required in the DMZ and limit access to anything on the LAN to only what is required.
However you have to make some assessment of the risk. Is the git server going to be open to the world or only restricted source IPs?
The term DMZ used here implies it is exposed and needs to be walled off from other subnets but that might not be the case. Or at least not in the traditional sense.
Steve