Everybody who has participated in this thread sharing ideas and experiences has helped me think. Big thank you!

I see this thread helping many people.

That is a point I am finally grasping. KISS. The terms were first used in this thread while referring to limiting this system to a gateway/router/firewall. That is where my current design is now leaning. Move the additional features to someplace else on the LAN. Do not try to create an all-purpose device like so many off-the-shelf devices.

Richard Cranium raised good points to "...NOT put your DHCP server in the DMZ. Nor your internal DNS server. Nor your SMB server."

My current strategy is I am drafting my future blog articles. The drafting process further helps me think about my design criteria. I find that many times when I want to learn or articulate something that writing or teaching others is a great way to unfold the ideas.

In the end I want the system to be reasonably secure yet be maintainable without significant loss of convenience.

I haven't yet decided how much I want to isolate this gateway. As this will be a minimal install there will be fewer patches. Likely I'll compromise. I won't provide the gateway with NFS access to the local Slackware repo mirror or SSH access to LAN systems, but I could SSH push patched packages to the system and then manually login and use upgradepkg rather than slackpkg.

I have thought some more about how a system compromise likely would unfold. I accept that no matter how much I try, I will be unable to stop malicious actors from discovering something about the LAN. But discovering something is not the same as further compromising.

Currently my thoughts about "isolating" the gateway are basically limit the number of services and packages. I can't predict zero-days, but if the system footprint is small I reduce how much I might have to deal with them.

Nah, I thought of the idea of two basic firewalls during the original conversation. Strictly off the apex of my cranium.

Implementing an IDS/IPS system on your GW will still keep it "transparent" and might help in actively blocking an attack. Careful, these systems are resources monsters and you can easily kill the CPU & fill the RAM. I used snort for many years until I got tired by fighting my way through all the increasing complexity of rules (my own collection included). I'm also not logging too much on iptables, but only for forensic purpose, just to know/understand what(&from where) hit me, that's if I'm ever getting hit. I'm not that curious to learn that I've just been portscanned, wow, how cool is that, it happens every few minutes anyways... boring.
But this is me and my experience & opinion, I encourage people to make use of such IDS/IPS systems. Some are available on SlackBuilds:
http://www.slackbuilds.org/repositor...network/snort/
+
http://www.slackbuilds.org/repositor.../network/psad/
http://www.slackbuilds.org/repositor...work/fail2ban/
http://www.slackbuilds.org/repositor...work/sshguard/
+
search on the internet for some others.

I'll just jump in to point out that the entire 10.x.x.x network is available for your internal use.

Most commercial gateways default to the 192.168.x.x block, but for any internal network, you have an astonishingly large pool of IP addresses to use with fairly easy subnet masks. Indeed, the DMZ can live in the 192.168.x.x world, while your internal LAN can live in the 10.x.x.x world.

I'll also add that any and all IoT devices should be in their own subnets as much as possible and they should not have the slightest clue about the rest of your network.

Do you use a DMZ?

@Richard Cranium
10.0.0.0/8 is a "sexy" network many people are using, not so much the "ugly" 172.16.0.0/12, useful for VPNs

@upnort
A small clarification, in post #75 I stated:
and was actually meaning that I'm not splitting the subnetworks, I use a whole subnetwork instead (plenty available). For instance, out of the private 192.168.0.0/16 network I'll use the entire 192.168.10.0/24 subnetwork. Splitting a subnet is usually also called subnetting, thus confusing.

Besides, privacy related, amazed what these Smart TVs are actually sending back home, and how many "homes" there are (I used to care about the vendor home and google analytics - filtering them in my firewall). My "Smart TVs" are actually turned into dumb monitors and the Smart part delegated to Kodi, which is obviously running on Slackware and handled properly (filtered & tamed).
https://www.schneier.com/blog/archiv...ng_by_sma.html

I don't at the moment, mainly due to idiocy. All that I would put in it would be my IMAP server; I was considering moving that to either a container or a raspberry PI. I do have the double firewalls that would isolate the DMZ in place.

Through the years I have toyed with the idea of some cameras to watch wildlife, but that never happened. A corollary is indoor cameras for security.

At the moment I want only a VPN and SSH for external remote access. I plan to use port knocking to open ports that are forwarded to the LAN. At the moment I'm not seeing a need for a DMZ at my end. There are no public facing servers and no IoT devices.

@upnort

In post #76 you said all the inputs helped you to think, I'm always happy to help. Now, let's try to progress to the next level after thinking, which should be understanding
Your remote access point is a service that you open up for the world, a server so to say, and it requires proper handling from security PoV. To make matters worse, the purpose of this service is to allow direct remote access to your LAN stations, thus a DMZ is the minimal security enclave you require for this service and it's by far not enough. Network segmentation/separation/isolation (achieved through VLANs(ideally) or firewalls), protecting both your GW and your LAN stations from the service running in the DMZ, limiting the fallout in case this system is getting compromised, should be also implemented.
https://en.wikipedia.org/wiki/Network_segmentation
This is a distilled summary of what I (& Richard Cranium) was "preaching" until now.

If, based on the concerns you exposed (operational complexity/energy consumption/laziness? ), you choose to ignore them, then you're left with no serious alternatives but to either expose your GW or your LAN stations directly to the "horrible outside world".

#### This is not an actual advice, but just an EXAMPLE/SIMULATION. I discourage everyone to adopt and implement what is written in this section! ####

One unserious solution would be to run a VPN server on your GW, open the access to it through your port knocking and connect the LAN stations to this VPN server (and VPN network) and set the OpenSSH on the LAN stations to listen only on the tunneling interface (VPN network). Do not allow OpenSSH connections from outside on the GW, neither directly nor through the VPN.

Another unserious solution would be to access the LAN stations individually on VPN from outside, use several point-to-point VPN connections, open the ports on your GW with the port knocking system (you'll open all of them even if you only need one) and only traverse the GW. This way at least you'll keep the GW "transparent" and secure, even after your whole LAN is compromised ...
In the firewall I presented in #72, for general purpose usage, I'm forwarding all the traffic both-sides trough the NAT with the two lines:
For this second unserious solution you can limit the new connections coming from outside to the LAN stations and restrict them only to the VPN ports, for example 10001,10002,10003 (your 3 LAN stations that you want to connect to):
OpenVPN simple PtP HowTo:
https://openvpn.net/community-resour...ey-mini-howto/

#### End of EXAMPLE/SIMULATION ####

Mention: the above EXAMPLE/SIMULATION section is the dumbest thing I ever conceived and I'd never implement it on my own

1 members found this post helpful.

My understanding is the gateway WAN side is always exposed to the outside world -- unless you are advocating two separate devices: a firewall that is exposed to the outside world and a gateway inside the firewall.

I do not have any public servers or IoT devices. I don't see the need for a DMZ or two separate devices. A Slackware system can be both a gateway and a firewall.

My understanding of a DMZ is a subnet of computers inside the gateway/firewall that is publicly accessible. Using NAT the firewall allows access to the DMZ subnet but not to the LAN subnet.

Most topography drawings I have seen show three NICs in that setup: WAN, LAN, DMZ.

If any system on the DMZ subnet is compromised, through network segmentation, no access to the LAN is possible and a malicious actor cannot find or see the LAN subnet.

Placing the VPN portal in the DMZ means there is no access to the LAN and files, which is the entire purpose of the VPN.

Normally all WAN side ports will be closed. My understanding is to use port knocking at the gateway/firewall to open port forwarding. The port forwarding would open one port to a VPN server that has access to the LAN.

Should a malicious actor find the open forwarded port, without the appropriate credentials that person will not have access to the VPN. OpenVPN supports adding a pass phrase as well that will foil connecting even if the certificates are stolen.

Unless there is a zero-exploit with OpenVPN, always possible, connecting through the port forwarding to a LAN system port 1194 will remain secure without credentials/certificates. My understanding of port forwarding is a malicious actor does not not know what port is open on the internal side of the port forwarding. The actor only knows what port is open on the WAN side. The actor must guess with brute force to discover the actual service that is open.

A picture of what I thought I was going to create:

Internet <---> (WAN) Slackware Gateway/Firewall (LAN) <---> Switch <---> Computers

The Slackware Gateway/Firewall will have two NICs, WAN and LAN. The system will use IP forwarding and iptables to allow traffic from the LAN to the WAN but not vice-versa. Anything incoming on the WAN that was not requested is dropped.

The gateway WAN side is indeed always exposed to the outside world and the kernel for sure, but as I've mentioned earlier, the kernel is pretty much safe from remote code execution exploits. Not that much safe from denial of service attacks (such bugs are occurring more often), but such attacks would be counterproductive for a malicious entity and will still keep you safe (GW just crashing).
The one service you're exposing is the port knocking and that, depending on how it's designed, can present an attack surface for code execution, how large/serious depends on the complexity and robustness of the code. It should just inspect the packets coming on the listening port, look into them to identify the payload and drop them immediately if invalid (not containing the expected cryptographic key).
No comment.

On your other points, please realize that you're looking to achieve remote administrative access to your LAN network and not only starting up a web server that you can 100% isolate from your LAN. You cannot and should not isolate the LAN stations from themselves and if one of those stations is getting compromised, the whole LAN is exposed, including all the services that you run on that LAN - thus, the attack surface becomes large enough for many potential attacks. This is why I suggested an intermediary access point, enclaved in a DMZ with limited access to your LAN (only VPN) and no access whatsoever back to the GW (access meaning that the GW will just drop everything else than VPN originated from this system to your LAN and everything coming from this system to your GW (NEW connection with the destination GW)). It will also save your GW from acting as a server - a listening service with complex code behind, with a greater attack surface. If your GW, which is doing the orchestration and is connected to everything, is compromised, then everything else becomes futile.

...
You should put all the services that you want to access from outside in DMZs, separate would be ideal ... and I thought you only needed remote administrative access and not exposing your entire LAN to the outside world.

Reading this short section could be also useful:
https://en.wikipedia.org/wiki/Securi...rity#Criticism

P.S.
It shouldn't care in this stage about the unique port that is open on your internal system, the packets sent by that actor will traverse the GW (given the port knocking has been activated) and reach the internal system (service). The internal system (service) will respond back, then the packets will be forwarded back to its originator (outside actor) by the GW. Not brute force but probing and the service will respond to the actors probes, unless you modify the service code.

Just a "dumb" nmap scan can already identify the service, without correlating it to the expected "standard ports":
https://nmap.org/book/scan-methods-i...ocol-scan.html
"
Like open ports in the TCP or UDP protocols, every open protocol is a potential exploitation vector. In addition, protocol scan results help determine the purpose of a machine and what sort of packet filtering is in place. End hosts usually have little more than TCP, UDP, ICMP, and (sometimes) IGMP open, while routers often offer much more, including routing-related protocols such as GRE and EGP. Firewalls and VPN gateways may show encryption-related protocols such as IPsec and SWIPE.
"

1 members found this post helpful.

This is a home network, not business. Nothing facing the public. There are no servers I want to start on the LAN. While I could perform administrative tasks after remotely connecting to the LAN, the primary purpose for remote access is accessing files.

I'm not interested in streaming online services through a VPN connection. I'm not interested in using my home VPN as a portal for browsing the web.

I am planning the gateway only to do routing and firewall. Any LAN related service will be on the LAN. For example, DNS, DHCP, SSH, and VPN services will not be on the gateway. Any remote access to the LAN will be through port forwarding. A tunnel.

Yes, but now we are entering the realm of esoteric speculation.

While I want remote access to the home network, I don't need access. I could very well never open any WAN side ports.

It doesn't matter, bad security design remains bad regardless of the scope.

Not speculation, just time to invest and audit/test the code
It's open source:
https://github.com/mrash/fwknop

Why didn't you say so from the beginning? Wasted so much effort telling you that you're doing it wrong with your remote access design
Well, you have already a lot of info for a simple GW&Firewall on Slackware in this thread.

1 members found this post helpful.

Because I want remote access. I don't see the bad design. Millions of people run VPNs and SSH directly off their off-the-shelf routers. I don't have public facing systems and I don't see the need for a DMZ. Perhaps I'm dense or stubborn.

Whether true or false, nobody likes being told in their face they are doing something wrong. Tact and diplomacy go a long way when helping people. I added the statement that I don't need remote access because despite your previous good faith effort, the information overload has turned the thread sour for me.

Yes, too much information, which can lead to confusion. The more I try to read through all the postings the deeper down the rabbit hole I feel. I'm exhausted from the information overload. All I want is a simple gateway/router/firewall with port forwarding to a VPN and SSH.

Again, it's not an easy subject and in all my arguments I was referring to the established practices belonging to the science of information security. It's a science and not a philosophy, covering many aspects of the security field. Speaking of "information overload", just have a look at:
https://en.wikipedia.org/wiki/Information_security
https://en.wikipedia.org/wiki/Computer_security
https://en.wikipedia.org/wiki/Security_engineering

If you feel that I hurt your feelings for being too "straight" with my last joke-statement (it contains an emoji at the end), I do apologize, even if I don't feel like, considering that you just misinterpreted it. The tongue-in-cheek message was "Here we go again..."
You should realize that even if I was trying to help you directly, this is a public forum and other people can&will get inspired by what is written here. I just don't want to mislead anyone with fallacy arguments like your generalization about the millions of people that don't know better, but provide best practices (best of my knowledge) as references. Worth to mention again that these are best efforts and not perfect solutions.

Just to recap and detail my proposal and remind you that it's only tailored for persistent automated attacks (port scans, probing and active exploitation attempts) that can (and will, according to how abundant they are lately) occur while you have your ports open (port knocking activated) and your listening service (VPN) exposed in public. It is public, even if you don't advertise it as such!
The security layers I proposed and apparently got accepted on your side:
PortKnocking->Firewall->VPN->SSH
- PortKnocking&Firewall are generic and limited protections (PortKnocking can be left activated for longer periods (while you're active) and the firewall is limited to filtering (no identity and access management capabilities))
- VPN&SSH are specific and redundant protections, IAM capable. If the upper VPN layer is compromised SSH still stands and the odds to crack them both at the same time is minimal. If the VPN Server and its underlying DedicatedAccessPoint are zombiefied (taken over), the only "useful" information that remains visible (to sniff) on that system are encrypted SSH streams traversing the VPN Network.

Then the network topology and solution diagram for the remote administrative access solution I proposed (the ideal case with a dedicated NIC for the DedicatedAccessPoint):
- vulnerabilities are usually exploited on listening services and not on connecting clients
- if the VPNServer on the DedicatedAccessPoint is compromised, the GW will be isolated (it's own firewall rules) and the LAN exposure limited, again by the firewall rules inside the GW
- the LAN stations on the LAN network will not accept new packets from the DedicatedAccessPoint, again a GW firewall rule prohibiting those
- even if the VPN traffic (VPN port) initiated by the the LAN stations is allowed to reach the DedicatedAccessPoint, these LAN stations won't run a listening VPN service but only VPN clients initiating connections on their own to the DedicatedAccessPoint
- after being compromised, if the VPN Server on the DedicatedAccessPoint is kept alive by the "malicious actor" and the LAN stations VPN clients are actively connected to it, the only listening service that is visible through the VPN on the LAN stations is the SSH (or an encrypted VNC service like Tiger VNC, if you need more than simple shell access)
- thus, the damage is contained on the DedicatedAccessPoint if the only service that you open for the outside - the first layer -> VPN Server is getting compromised
- obviously, you could open more services on some particular LAN stations through the VPN. Note that you'll increase the attack surface and I'd suggest to only use encrypted services (sftp&co)
- ideally, for any service that you want to open for remote access, a dedicated system with a dedicated DMZ should be considered.

Now, the alternative, the poor man's solution connecting the DedicatedAccessPoint to the LAN eth0 but still on a different subnetwork.
- if the DedicatedAccessPoint is compromised (VPN Server), its network configuration can be changed to match the one of the LAN and the only protection you can implement is a static arp entry on both the GW and the LAN stations matching the DedicatedAccessPoint MAC XX:XX:XX:XX:XX:XX, like:
But as we all know, even MAC addresses can be easily changed/cloned.


The other solutions that were discussed and I disapproved for not beings serious (dangerous):
- your solution to access the GW directly from outside:

WAN(eth1)--PortKnocking--Firewall--VPNServer--SSH--GW--Firewall--LAN(eth0)--SSH--LAN(stations)

- here, if the VPN server running on the GW is compromised, local access on the GW will be achieved and the whole network will be exposed
- you can even skip the VPN and let only SSH active, there is no layered security

- my "dumb" proposal from post #83:

WAN(eth1)--PortKnocking-Firewall--GW--Firewall--LAN(eth0)--VPN-Point-To-Point-Listening-Services--SSH(throughVPN)--LAN(stations)

- this will at least protect your GW, but on the LAN stations, even if it's a PtP VPN solution, there are still VPN listening services that can be exploited.
- once a LAN station is compromised (the VPN service), then the whole LAN network will be exposed and potentially also the GW (from the particular LAN station that is allowed to connect to it for administrative purposes)


Other/final points:

I noticed you started a thread where you're trying to strip Slackware from unnecessary packages that you might consider dangerous to leave available on the GW (or any other system that you want to expose). IMHO it's pointless, in an attack (even automated one), first thing after the breach, the "malicious entity" will check the system architecture and download a matching (previously prepared & statically compiled) binary package that will contain all the toys needed for further exploitation.

I'll stop here, this thread has gone way beyond your original question form post #1 and it's not Slackware related anymore. You state that you're fighting the "information overload" now, but it was a continuously changing landscape and there were many ideas discussed, no wonder that it has come to this...

If you need any particular usage help with the utilities Slackware is providing for realizing what I proposed, feel free to ask, I'll be happy to help.
For the other unserious solutions you already have what's needed and I won't spend any more time on them since I totally disagree (on) and discourage them.

1 members found this post helpful.