On 7/10/23 16:15, Marc Chamberlin via openSUSE Users wrote:
Bob Rogers wrote:
From: Marc Chamberlin via openSUSE Users users@lists.opensuse.org Date: Sun, 09 Jul 2023 22:48:31 -0000 OK, so now you've renamed the zone for what it does (though a simpler, more rose-like, name might have served better). LOL, OK how about IMZ for internal militarized zone? I am not clear why the network hawks chose to use a military term (DMZ) for describing a particular type of network design, but I really don't care about the name, just the functionality.
I'm sure you know the derivation of the term DMZ. I remember it being used in the Viet Nam War to denote what used to be known as the Dead Man's Zone, and refers to a defensive capability. It's difficult to defend yourself in hand-to-hand combat, it makes much more sense to keep the enemy completely separated from your internals. The DMZ gives you that separation.
But I think we're all still a bit unclear on what you hope to accomplish by having a separate network for external traffic. If this traffic all goes to the same hosts anyway, what difference does it make? In terms of security, or ease of configuration, or anything else? What I want is for each system to present a different set of capabilities depending on where the access to that system is coming from. For example the security cameras will require authentication if access to the computer that controls them comes from the internet via my IMZ zone. So I want to route all traffic that comes from the internet, destined to a particular public IP address, to be routed onto the IMZ zone and passed to the computer that controls my security camera. But if access comes from my internal zone, then no authentication will be necessary.
Same goes for my computer that controls a telescope. I will want to be able to do things with the telescope (that potentially could damage the telescope, if mis-used), if I access it from my internal network (or from a VPN). If a guest accesses the telescope via a particular public IP address (that I own), that user will be routed via my IMZ zone to where he/she can access the telescope control computer via a different NIC and thus a different web interface that is more limited in capabilities.
In other words, each of my computers will be "two-faced" and depending on how the computer is accessed, will determine which side of the computer's "faces" will be presented. Andrei seems to be implying that this particular use case is uncommon and possibly not easy to support. To me, as an object oriented designer/developer this type of usage of computers on a network seems to be an obvious one and should be easily supportable.
In my humble opinion, having a two-faced host, with one of the interfaces directly connected to the untrusted Internet is dangerous. In a perfect world, with perfectly correct configuration files and bug-free software it might work for a while, until the next update introduces new bugs. I think it makes more sense to differentiate capabilities with different login credentials. TCP/IP security cameras allow this, for example. I'd put the servers that need public access in the DMZ and treat them as expendable. They could be reached from the Internet and from your internal subnet(s), but traffic would be blocked from going from the DMZ to your trusted networks. You could easily set this up with an off-the-shelf firewall. I've been using Zyxel routers myself, but there are many options. A fun one would be to take an old desktop, install multiple NICs, and run it as a firewall. I did this once with LRP (Linux Router Project). The desktop had two NIC's, a bit of ram, and a 3.5-inch floppy drive. The software booted off of the floppy and ran out of RAM, it didn't have an internal disk drive. The floppy was write-protected, so if the firewall became compromised you only had to reboot and you're off to the races again. Alas, LRP is dead, maybe pfSense would work better? IOT devices should certainly never be allowed in an internal network. Regards, Lew