LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 09-21-2019, 08:59 PM   #61
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,672

Rep: Reputation: Disabled

Quote:
Originally Posted by abga View Post
On complex networks / "multi-zones", try making use of VLANs for defining and isolating the networks (could also be zones), don't just use a "master" GW with a "master & all-knowing"
Did you read the thread? That's precisely what I'm doing.

(As for firewalls being single-point-of-failure, VLANs do not help with that. For gateway redundancy one would use a first-hop redundancy protocol, but even that doesn't really work seamlessly with NAT setups.)
 
Old 09-21-2019, 09:14 PM   #62
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,211

Rep: Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640
Quote:
Originally Posted by Ser Olmy View Post
Did you read the thread? That's precisely what I'm doing.

(As for firewalls being single-point-of-failure, VLANs do not help with that. For gateway redundancy one would use a first-hop redundancy protocol, but even that doesn't really work seamlessly with NAT setups.)
No I didn't, I stopped at those "temporary rules to the top of the INPUT and FORWARD chains", said already that it was to complicated for me to follow.
My last point was to diversify, employ more technologies, define separate networks, VLANs, make use of advanced routing (iproute2 utilities), don't just route everything and don't just rely on the firewall.
 
Old 09-22-2019, 05:40 PM   #63
karlmag
LQ Newbie
 
Registered: Apr 2014
Distribution: Slackware
Posts: 22

Rep: Reputation: Disabled
Quote:
Originally Posted by upnort View Post
I'm interested in reading thoughts and caveats from those of you using Slackware as a network gateway system -- router, firewall, DNS, DHCP, VPN, VLANs, etc. Not a file or any other server. Just gateway services.

Bare metal? Virtual? How many NICs? Wireless AP (hostapd)? Web browser interfaces to display various stats? QoS?

History first;
All my firewalls have been bare-metal Slackware.
I used to have a firewall (iptables)... I *think* that was an old Fujitsu Siemens desktop machine.
When that all of a sudden died I had to quickly rummage through my piles for a somewhat suitable replacement.
Ended up with a HP Compaq desktop (I may remember the brands of this and the first in reverse).
This second one had to run without the lid on top, because it only had half height expansion slots, and my dual PCI NIC was full height only. Looked a bit weird, but it did work for a couple of years.
But one morning (before noon - that was when it stopped responding) it just died.
Finding a machine with pata port this time was a bit of a stretch, so I ended up rushing a machine intended to become the firewall replacement into place. Newer Slackware, but the same iptables setup as before.
Fine and dandy enough I suppose.
Specs; GA-J1900N-D3V, Quad Celeron 2.0GHz, onboard (4c/4t) w/8GB RAM (because I could). Dual onboard nic + a dual nic in the pci slot. Nicely placed in a mItx case. I also have a dual Gb <-> usb3 NIC if I ever need more than 4 segments. Probably totally overkill for my needs, at least for now.
However, I also have a second, identical machine to the one rushed into service that I had up'n'running for a while in parallel to the "primary" firewall.
Main difference from the primary one is that I have singed my brain trying to set up nftables on it.
I also have two ISPs, but never before fully taken advantage of that. I hope for that to change, but that will require burning off quite a few more brain cells I think.

Besides that I don't think I have that many "weird" requirements for my firewall.
I don't do wifi (yet - subject to change), but my needs for that is limited. I would, however want to wedge that in as a separate network segment.

Thanks
--
KarlMag
 
Old 10-03-2019, 09:48 PM   #64
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Original Poster
Rep: Reputation: Disabled
I am writing a check list of sorts for this project.

I stopped to ponder a single point. How should I configure the system to NOT having access to the LAN? While I want and need remote access to the gateway system, should the system ever be compromised through some oddball zero-day exploit, I would prefer being able to block any knowledge of what exists on the LAN side.

Disable SSH client?
Do not install nmap? netstat (net-tools)? ping (iputils)?
Configure NFS/Samba to not allow connections from the gateway?

Probably no need to "disable" the SSH client. I only use keys and no password logins. Without network tools scanning the LAN side becomes a challenge.

I was thinking that rather than assign a traditional X.X.1.1 IP address, instead assign something like X.X.1.129 and then configure LAN systems to only allow X.X.1.0/25 connections.

Conversely, if the system was compromised, likely I would not know immediately and I would be unable to stop the intruder from installing missing network tools.

Thoughts?
 
Old 10-03-2019, 11:03 PM   #65
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2
Posts: 3,470

Rep: Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813
Looks like you either need two computers or one computer with a docker image/VM that acts as a simple-stupid NAT router.
 
1 members found this post helpful.
Old 10-03-2019, 11:32 PM   #66
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,211

Rep: Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640
Quote:
Originally Posted by upnort View Post
I am writing a check list of sorts for this project.

I stopped to ponder a single point. How should I configure the system to NOT having access to the LAN? While I want and need remote access to the gateway system, should the system ever be compromised through some oddball zero-day exploit, I would prefer being able to block any knowledge of what exists on the LAN side.
You can't do it with your rather primitive home setup with only one defined LAN (both physically&logically), well, you could configure the LAN clients to block any new incoming packets from the "insecure" GW, but that won't help the bad guys from identifying your topology, spoof the IP and try to hack your clients too.
I'd suggest to not use the main GW as a remote access point, only open the remote access port on the main GW with the port knocking system and forward the traffic to a different and dedicated system - buy a cheap SBC, use it as a remote access system only on a different LAN (you could define as many LANs as you want on the main GW), run a VPN service on your SBC (again on a different VPN network on which some other of your LAN clients that you want to access are configured and connected with their VPN clients) and start ssh listening on the VPN. From outside you initiate the VPN first and then the ssh (both) to your internal SBC. Don't allow the SBC to initiate new connections on the internet, block them in the GW, that's for the case the SBC is getting compromised.
Then take my advice from some posts above, on your GW don't route/forward everything to everything, set the FORWARD on DROP and only allow the required traffic - in this case only the VPN traffic between the LANs (the SBC LAN and your internal wired/work LAN). You'll limit the bad guys on hammering only the VPN clients and the ssh, thus limiting the exposure.
The same should be done for the WiFi - which you should consider insecure&broken by default and define a special LAN for it on your GW, do the NAT - allow it on the Internet, but don't just forward all the packets between that WiFi LAN and your wired (work) LAN, be very specific if you need to access something from it.
And .. the same should go for the dumb "Smart" things and IoT stuff (TV, Underwear Dryer & co ) in your network, the enemy inside, that you cannot control and are utterly insecure. I have a special "Fun Network" LAN dedicated for them and allow them to talk to each other and go out on the internet, but don't forward anything to my work LAN.

Quote:
Originally Posted by upnort View Post
Do not install nmap? netstat (net-tools)? ping (iputils)?
Configure NFS/Samba to not allow connections from the gateway?

Probably no need to "disable" the SSH client. I only use keys and no password logins. Without network tools scanning the LAN side becomes a challenge.
Now this is really funny, they'll surely have a hard time getting the tools they need ... get serious

Quote:
Originally Posted by upnort View Post
Conversely, if the system was compromised, likely I would not know immediately and I would be unable to stop the intruder from installing missing network tools.

Thoughts?
None. If you'll be able to spot 0day attacks, you'll be a rich man for sure. Your only viable option is to limit the damage, design the system to fail safe/limit the exposure.

'nuff Slacking for today. Actually this isn't that much Slackware anymore and I fear I'm going way off-topic (Slackware Forum) with my inputs.
 
Old 10-04-2019, 12:01 AM   #67
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,211

Rep: Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640
@upnort
Well, Richard Cranium is definitely experienced/knowledgeable, while I was composing my (rather long&boring) post, he already suggested to use a "simple-stupid NAT router", right on point, not so sure about the stupid part, I prefer to have it highly intelligent.
Pretty much what I was advising, use the GW only as a GW/router/firewall, bullet proof and "transparent" to the inside&outside, untouchable&unbreakable so to say, and only orchestrate the traffic&networking&filtering on it (and the port knocking). Limit the administration of the GW to only one internal (trusted) host on your LAN.
... put a sticker on your GW with the motto "oblivious to the world around" to remind you about the design philosophy.
 
Old 10-04-2019, 12:51 AM   #68
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2
Posts: 3,470

Rep: Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813
Quote:
Originally Posted by abga View Post
@upnort
Well, Richard Cranium is definitely experienced/knowledgeable, while I was composing my (rather long&boring) post, he already suggested to use a "simple-stupid NAT router", right on point, not so sure about the stupid part, I prefer to have it highly intelligent.
Pretty much what I was advising, use the GW only as a GW/router/firewall, bullet proof and "transparent" to the inside&outside, untouchable&unbreakable so to say, and only orchestrate the traffic&networking&filtering on it (and the port knocking). Limit the administration of the GW to only one internal (trusted) host on your LAN.
... put a sticker on your GW with the motto "oblivious to the world around" to remind you about the design philosophy.
Well, don't beat yourself up too much. (JOKE: That's why we are here!)

I had written something a little more detailed and then deleted it. Something similar to what I had written follows.

There's a concept of a DMZ in networking; it's the portion of your network that knows something of the outside world (the WAN) but knows the absolute minimum amount required to function about your internal world (the LAN).

You'd put your IMAP server in the DMZ (assuming that you want to access it from the external world). You would NOT put your DHCP server in the DMZ. Nor your internal DNS server. Nor your SMB server.

Stuff like that.

The "Simple and stupid" bit is along the KISS principal; make the thing that talks to the horrible outside world simple to understand and stupid enough that you can predict how it will react to inputs. (My ISP's router knows to keep ports initiated from inside open and the address of my gateway, but that's it.)

EDIT: After reading more closely, @abga's points are on target as always. When in doubt, listen to him versus me.

Last edited by Richard Cranium; 10-04-2019 at 12:52 AM.
 
Old 10-04-2019, 08:30 AM   #69
EdGr
Member
 
Registered: Dec 2010
Location: California, USA
Distribution: Slackware
Posts: 214

Rep: Reputation: 90
I maintain two networks: a wired network for important stuff, and a wireless network for Internet access.

The wired network connects my two HEDTs and a laptop. All have static IP addresses. There is no router, just a gigabit switch. This is a truly private network: one must plug in a cable to connect to it.

The wireless network provides Internet access for two laptops via an AT&T WiFi router. The laptops use DHCP and iptables filtering on the wlan0 ports.

This arrangement evolved from the dial-up days, with the WiFi router replacing a dial-up modem.

I like this arrangement because it is very secure, independent of what the AT&T WiFi router may or may not do.
Ed
 
Old 10-04-2019, 11:23 AM   #70
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Original Poster
Rep: Reputation: Disabled
Quote:
Now this is really funny, they'll surely have a hard time getting the tools they need ... get serious
I did poorly allude to the futility of stopping somebody when I concluded, "Conversely, if the system was compromised, likely I would not know immediately and I would be unable to stop the intruder from installing missing network tools."

Regardless, lots to think about. Adding Yet Another Device to the project seems like going too far. Extra devices, electricity, and maintenance.

Originally I wanted to replace dodgy insecure off-the shelf devices and not create an enterprise threat network. Perhaps a first approach is do nothing but create a simple gateway/router -- no other services. I did plan to keep all WAN ports closed. I was thinking about including the AP in the device, but now am wondering if services such as AP, DHCP, DNS, VLANs, VPN, SSH belong outside the gateway/router. Port knocking would support port forwarding for remote VPN and SSH.

Conversely, there is a point of diminishing returns. Even if the additional services are included in a single device, keep the device patched timely and WAN side ports closed except when needed. I suppose this is about the optimal security that can be achieved for most people.

I'm going to let all of this fester in my head for a while.
 
Old 10-04-2019, 11:17 PM   #71
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,211

Rep: Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640
@upnort
In my post #66 I presented a solution in practical terms, without emphasizing too much on the theoretical part of DMZs. If you take an abstract view on my instructions you'll understand that I'm DMZ-ing pretty much everything around the work LAN, actually I'm going even further, isolating the networks I cannot control & trust. Richard Cranium did a great job in briefly explaining the classic concept of DMZ and the requirement for such a setup in his post #68. What he didn't do so great was to tell you that you should listen to me instead of him and now you're back to the drawing board
Too late now, still, if you want to learn a little more about the DMZs, Wiki has a short and condensed article with some nice schematics:
https://en.wikipedia.org/wiki/DMZ_(computing)

If your GW is not exposing anything to the outside and only forwarding the traffic to a remote access system, chances to hack it are almost 0. The only thing you are constantly exposing is the kernel, which is pretty much safe from remote hacks. Well, pretty much:
https://www.theregister.co.uk/2017/0...x_kernel_flaw/

In your actual setup you don't leave any ports open on the WAN on your GW, but you do after running the port knocking, and what you need is presumably direct (first hand) administrative remote access to the whole LAN behind, which from security PoV equals a "disaster" if it's getting hacked somehow.
If you are so concerned about electricity and maintenance, I'd suggest to get a 5 bucks Pi Zero board (the simple one without the crappy WiFi/BT chip & firmware), that easily can handle remote access traffic - OpenVPN highest throughput measured here at ~ 6Mbps, and an USB Ethernet card, setup a Slackware ARM system on that thing and use it as an access point with the conf I suggested in #66. Almost 0 maintenance, throw and forget it somewhere under your desk and the electricity consumption for this board tops at 200mA @ 5V + max. 100mA for the USB Ethernet Card = 300mA @ 5V, that's 1.5W/h (roughly - the 5V DC adapter is not 100% efficient).
It'll take approximately 27 days for the Raspberry Pi Zero board to eat 1kW of electricity, that's almost a month of operation on 13.19 cents.
https://www.electricchoice.com/elect...ices-by-state/
"The average electricity rate is 13.19 cents per kilowatt hour (kWh)."

The other day I was reading an article about how bad the IoT devices, including off-the-shelf routers, are doing with respect to security.
https://www.schneier.com/blog/archiv...ing_the_s.html
https://cyber-itl.org/2019/08/26/iot-data-writeup.html
Setting up and running a Linux Gateway turns now to be a necessity. Slackware is doing just great for such a job, comes packed with everything that's needed and flexible enough to configure it for any required scenario.

Last edited by abga; 10-04-2019 at 11:19 PM. Reason: he = the
 
Old 10-04-2019, 11:30 PM   #72
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,211

Rep: Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640
@upnort
In some other thread related to the rc init scripts we discussed about a standard rc.firewall script that should maybe be available in Slackware. You suggested a specific script for a workstation and one for an advanced setup (multiple interfaces). I remember telling you that such a firewall is hard to design, pleasing everyone and everything, but got some time and created an universal one. It won't do any harm, unless you switch from eth0 to wlan0 and don't update & relaunch it, and it won't help too much either.
It's the simplest form I could conceive, without absolutely no scripting and I provided some help & hints on all the sections.
Code:
#!/bin/sh

#Some definitions first
#Internal interface, eth0, wlan0, etc - note that the firewall script will fail if the defined interface doesn't exist
intif="eth0"
#External interface(s) uncomment and define if available
#extif="eth1"
#External IP for the external interface, uncomment if available and defined static
#extip="199.99.9.9"

#Flush all rules & chains on IPv4
/usr/sbin/iptables -F
/usr/sbin/iptables -X
/usr/sbin/iptables -t nat -F
/usr/sbin/iptables -t mangle -F
/usr/sbin/iptables -t raw -F
/usr/sbin/iptables --delete-chain
/usr/sbin/iptables --table nat --delete-chain
#Set default policies on DROP for IPv4
/usr/sbin/iptables -P INPUT DROP
/usr/sbin/iptables -P FORWARD DROP
/usr/sbin/iptables -P OUTPUT DROP

#Flush all rules & chains on IPv6 - comment out if you disabled IPv6 in the kernel / blacklisted the ipv6 modules
/usr/sbin/ip6tables -F
/usr/sbin/ip6tables -X
/usr/sbin/ip6tables -t nat -F
/usr/sbin/ip6tables -t mangle -F
/usr/sbin/ip6tables -t raw -F
/usr/sbin/ip6tables --delete-chain
/usr/sbin/ip6tables --table nat --delete-chain
#Set default policies on DROP for IPv6 - comment out if you disabled IPv6 in the kernel / blacklisted the ipv6 modules
/usr/sbin/ip6tables -P INPUT DROP
/usr/sbin/ip6tables -P OUTPUT DROP
/usr/sbin/ip6tables -P FORWARD DROP

#### SINGLE INTERFACE - BASIC SETUP - Workstation & Server ####
### Minimal ruleset for basic protection on IPv4 ###
#Insert here all the DDoS, packet integrity checks, SynFlood, etc. protection rules you find interesting. Everybody has a few special ones.
#Additional packet logging definitions, if really necessary.
#And get back to the serious stuff.
#Enable loopback
/usr/sbin/iptables -A INPUT -i lo -j ACCEPT
/usr/sbin/iptables -A OUTPUT -o lo -j ACCEPT
#Allow outgoing traffic on the internal interface
/usr/sbin/iptables -A OUTPUT -o $intif -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
/usr/sbin/iptables -A INPUT -i $intif -m state --state ESTABLISHED,RELATED -j ACCEPT
#Allow outgoing traffic on the tunneling interface (tun/tap) - uncomment if available
#/usr/sbin/iptables -A OUTPUT -o tun0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
#/usr/sbin/iptables -A INPUT -i tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
#Allow ICMP on all interfaces (recommended for proper networking functionality)
/usr/sbin/iptables -A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
/usr/sbin/iptables -A OUTPUT -p icmp -m icmp --icmp-type any -j ACCEPT
#Allow DHCP traffic on the internal interface
/usr/sbin/iptables -A INPUT -i $intif -p udp --sport 67:68 --dport 67:68 -j ACCEPT
#Defense against portscans - lock portscanners out for 24h
/usr/sbin/iptables -A INPUT   -m recent --name portscan --rcheck --seconds 86400 -j DROP
/usr/sbin/iptables -A FORWARD -m recent --name portscan --rcheck --seconds 86400 -j DROP
#Remove the portscanners from the portscan list after 24h
/usr/sbin/iptables -A INPUT   -m recent --name portscan --remove
/usr/sbin/iptables -A FORWARD -m recent --name portscan --remove
#Allow OpenSSH connections on the internal interface
/usr/sbin/iptables -A INPUT -i $intif -p tcp --dport 22 -j ACCEPT
#Add any other services with their listening ports in the fashion presented above for OpenSSH
#Read the service documentation or use the netstat / lsof -i tools to learn/identify the listening port

### Minimal ruleset for basic protection on IPv6 ###
#For IPv6 replicate the IPv4 section above by using the appropriate /usr/sbin/ip6tables

#---------------------------------------------------------------------------------------------

#### MULTIPLE INTERFACES - ADVANCED SETUP - GW & Router on IPv4 ####
#Uncomment only the rules that are required for your setup
#Allow outgoing traffic on the external interface - required if interface is available
#/usr/sbin/iptables -A OUTPUT -o $extif -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
#/usr/sbin/iptables -A INPUT -i $extif -m state --state ESTABLISHED,RELATED -j ACCEPT
#If you plan to turn your system into a gateway, run NAT and serve you LAN clients, you have two options:
# Option 1 - If you have a static IP address on your external interface, then opt for SNAT, uncomment:
#/usr/sbin/iptables -t nat -A POSTROUTING -o $extif -j SNAT --to $extip
#Option 2 - If you have a dynamic IP address, allocated through DHCP on your external interface, then opt for MASQUERADE, uncomment:
#/usr/sbin/iptables -t nat -A POSTROUTING -o $extif -j MASQUERADE
#Forward the traffic originating from the internal interface (LAN) to the external interface (WAN/Internet) and vice-versa
#/usr/sbin/iptables -A FORWARD -i $intif -o $extif -j ACCEPT
#/usr/sbin/iptables -A FORWARD -i $extif -o $intif -j ACCEPT
#Make sure /etc/rc.d/rc.ip_forward is set one executable and launch it manually once

#if you need to port forward a service on your LAN through the NAT on the external interface - external IP, here you have an example for OpenSSH
#First allow OpenSSH connections on the external interface
#/usr/sbin/iptables -A INPUT -i $extif -p tcp --dport 22 -j ACCEPT
#Then add the DNAT port forwarding rule, substitute YOUR_LAN_HOST_IP with your actual IP - e.g. 192.168.0.10
#/usr/sbin/iptables -t nat -A PREROUTING -i $extif -p tcp --dport 22 -j DNAT --to YOUR_LAN_HOST_IP:22
#Alternatively use 192.168.0.10:2222 if OpenSSH is configured to listen on port 2222 on your LAN host

#### MULTIPLE INTERFACES - ADVANCED SETUP - GW & Router on IPv6 ####
#For IPv6 replicate the IPv4 section above by using the appropriate /usr/sbin/ip6tables
Feel free to adopt/correct/criticize (all of you) but please don't f.... it up with useless shell scripting, there are tons of useless firewall scripts on the internet, filled with conditional checking and "smart" solutions for everything and everyone, just go an improve those instead

Last edited by abga; 10-18-2019 at 02:29 PM. Reason: Removed the icmp rate limiting: -m limit --limit 2/second Any rate limiting that is not specifically sized could do harm.
 
Old 10-05-2019, 01:30 PM   #73
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Original Poster
Rep: Reputation: Disabled
Quote:
now you're back to the drawing board
Maybe, maybe not. This thread has grown longish -- lots to consider!

My original vision was to replace the off-the-shelf consumer do-everything Asus gateway/router/switch running DD-WRT. Human nature is to latch onto an idea and not immediately see other possibilities. Discussion and sharing helps see those possibilities and not rushing into a project helps too.

At this point the Asus device is my edge device and offers a bunch of features. My tunnel vision presumption was the new self-built gateway would include lots of features too.

I never fully trusted DD-WRT because the project is run as a playground, but there is no way this side of Hell I am going to run the native Asus firmware with all of its phone-home crap. Motivated by the Ars Technica article, I thought I could slowly build my own device and add multiple features.

Only after drafting my check list and notes did I appreciate the potential for this project to get complicated. Hence the latest question about isolating the gateway.

Currently the Asus device with DD-WRT does not provide easy access to the LAN. I can SSH into the device, but I cannot do the reverse because of using only keys and never uploading a public key from the router to anything on the LAN. I don't remember if DD-WRT even supports that. Tools such as nmap are not installed. Thus access is more or less one-way. I wanted something similar with the new gateway, but doing that is a challenge with an all-purpose distro.

I'm not naive enough to think a malicious hacker could not find a way to access the LAN, just that normally I don't keep a slew of ports open on the WAN side. Building a generic all-purpose device using Slackware means more packages and if compromised, a lot easier to hack and attack the LAN.

I understand the concept of a DMZ. Just that back to my original tunnel vision of one do-everything device I never paid much mind. Adding a DMZ means my original vision of one device grows into something more. I have spent the past few years reducing computer maintenance in the house. My original project vision did not include adding additional devices. Hopefully this long explanation explains how my mind got into a rut, so to speak.

I'm still letting the conversation fester in my mind. I need to review the entire thread. After festering in my mind if I need to add additional devices I will.
 
Old 10-05-2019, 02:18 PM   #74
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Original Poster
Rep: Reputation: Disabled
Quote:
I remember telling you that such a firewall is hard to design, pleasing everyone and everything, but got some time and created an universal one.
My current leaning is not to build an all-purpose do-everything device. Build only a gateway/router. Nothing more. Two NICs only.

That reduces the firewall concerns.

Side note: Eric's online firewall generator supports gateway configurations. I would use that as a starting point for the new gateway.

I'm still thinking of assigning the new gateway to something like X.X.X.129.

Currently all LAN systems here already only allow X.X.X.0/25 access. I configured that years ago as a light-hearted intellectual challenge to discourage curious house guests. There is a fully separate guest WLAN on a different subnet, but what if a house guest wanted to snoop on the LAN? All LAN systems use static IP addresses and any guest who tried to connect to the LAN by Ethernet is forced to use DHCP starting with .128. Thus Ethernet guest systems cannot easily find LAN systems.

With that design, if the new Slackware gateway is compromised the malicious hackers could change the device IP address to find systems on the X.X.X.0/25 subnet, but I would notice that quickly because all LAN systems would not find the gateway.

One caveat with "isolating" the new Slackware gateway is I would have to manually log in to update/patch the system. I would not be able to use my local LAN Slackware mirror as that would require NFS. Not a huge caveat as I plan to perform a minimal install, which will limit the number of packages and frequency of patching.

Currently on all LAN systems I run a cron job every minute to monitor login attempts. I just retested that by trying to SSH into the office desktop from the Asus router. Works great.

For outside remote access to the LAN I would need port knocking and port forwarding. Otherwise my current thought is WLAN/AP, VLANs, DHCP, and DNS, etc. all would be installed elsewhere on the LAN.

The office desktop is a file server for the LAN and remains on until lights out at night. That system likely could become my "other" system for the additional services. Perhaps just add the services or use containers and VMs.

DD-WRT does not well support port knocking. Currently on the Asus device remote SSH port is enabled all the time but on a non-standard port with password access disabled. The VPN gets enabled only after I SSH into the device. Key pairs only. My SSH private key is passphrase-protected. I would transfer that design to the new gateway but use port knocking to keep the SSH port closed most of the time.

I like these calm discussions. I'll never profess to be an expert on many subjects.

Edit:

Quote:
If your GW is not exposing anything to the outside and only forwarding the traffic to a remote access system, chances to hack it are almost 0.
While my current leaning is not to build an all-purpose do-everything device and build only a gateway/router, I did not overlook that comment.

As my current thought is no WAN side ports will be open without port knocking, the new gateway would be no better or worse than my current Asus device. More than reasonably secure. The only WAN side ports that ever would be open is SSH and OpenVPN. With password logins disabled I could expand the purpose of the new gateway to include other services and remain more than reasonably secure.

Back to letting all of this fester in my feeble mind.

Last edited by upnort; 10-05-2019 at 03:23 PM.
 
Old 10-05-2019, 05:34 PM   #75
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,211

Rep: Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640
Indeed,
Quote:
This thread has grown longish -- lots to consider!
It's not an easy subject and there are lots to consider because of the latest developments in inter-networking. Classical protection schemes are still to be used but not enough anymore. The "horrible outside world", as Richard called it, has been weaponized lately, big budget state actors are actively looking for "available resources" for their "agendas", complex attacks have been democratized (plenty of tools available for anyone to try) and then the abundant smart devices can be turned easily into threats (firmware level - crappy security models on BlueTooth/WiFi/Mobile Modems & on application layer - Android is notorious).
While still Slackware related, I'm happy to continue the discussion and hope that the thoughts and ideas exchanged here are beneficial for all the Slackers. As I mentioned, I've been using Slackware as a gateway for a very long time, actually ever since I started using it back more than 20 years ago.

There are some points in your latest 2 long replies that I would like to address and I'm trying to be short.
There seems to be a misunderstanding about the isolation and I'll try to elaborate. First there is the network isolation, even if the networks are being routed by default in the GW, not forwarding packets (or partially only) between them through a firewall rule is a form of isolation. Another one would be to isolate a network from the web, like I suggested with your access point external system, on a different network, not allowing it on the web, again through the GW - meaning you don't allow NEW packets originating from it to reach the web. Obviously, when you need to update that system, you'll temporarily allow it to connect to the Slackware mirrors through an iptables rule, canceling that rule after you finish.

Regarding the GW, I was using the terms "transparent" and "oblivious", meaning that its shouldn't give a damn on its own about the traffic that is traversing it. Not listening for incoming NEW packets on either side (WAN/LAN), that's dropping them by default, will bring it to that state of "I don't give a beep". Now, you have the port knocking system in place on the WAN side and that will listen on a specific port for a specific packet, containing the cryptographic payload and will (should) drop everything else. But for a port scanner that should be transparent. On the LAN side you need to control the GW and I suggested to allow connections to it (ssh/vpn/whatever) only from a specific&trusted LAN station.
You could even go that far and allow the GW to initiate new connections to the WAN only for the packets that are coming through the NAT, for the port knocking and maybe for some other services like NTP, but that would be an overkill IMHO and would be also silly, I mean, you don't trust your own system?

I'm not using subnets, find it complicated to play around with masks - can easily make mistakes, but only entire networks (it also provides me a little more control over broadcasts & stuff). If you only plan to use one interface for the LAN, you could employ aliasing.
https://www.kernel.org/doc/html/late...ing/alias.html
And your visitors can come prepared with some toys to investigate your connectivity:
https://play.google.com/store/apps/d...oid.fing&hl=en
Much like yourself, I treat mine with respect, I only allow them on the Fun Network, together with all the smart & IoT stuff. Warning them that they could be also guinea pigs for the "wild things" that happen on that network. I use a secondary WiFi for my own needs and I'm only traversing it through VPNs (don't trust the WiFi encryption).

iptables offers you the possibility to map a whole network of addresses onto another network of addresses by using NETMAP (not that popular on the web):
https://www.frozentux.net/iptables-t...tml/x4492.html

On AlienBob's script generated firewall:
https://www.linuxquestions.org/quest...1/#post5834627
Regarding the pretty redundant filtering of "weird" packets, have a read on the first answer from here (good to know):
https://security.stackexchange.com/q...ks-client-side
Starting with dropping everything and only focusing and allowing what's necessary is the easiest and cleanest way I learned from experience. even if I consider myself versed with the networking stuff, when I read a scripted firewall with many custom chains treating a lot of stuff I drop from the very beginning and don't bother about, I also get easily confused. Understanding the networking, simulating in my mind where the packets should and could flow, parsing the rules is difficult enough, don't need to bother with another layer of complexity, thank you very much. KISS baby!
On your idea of having two separate firewalls, just looked over the fence and noticed this:
https://wiki.debian.org/DebianFirewall
- was this your inspiration?

There's a feature you could consider & play with - VRF:
https://www.kernel.org/doc/Documenta...orking/vrf.txt
http://www.routereflector.com/2016/1...-vrf-on-linux/
https://ops.tips/blog/using-network-...olate-servers/

Then you could also just mark the packets you want with iptables (your firewall) and do the discretionary (advanced) routing with the iproute2 utilities, achieve the isolation.

I believe I mentioned it earlier, I'm also using (usually) OpenWRT on top of a Slackware GW, in a cascaded topology, doing double NAT - some might consider it stupid/silly, I don't care, it fits the purpose and I have way more control over the separation/isolation. I started using Slackware as a GW before the *-WRT became popular. Even after that, the routers supporting *-WRT were pretty high edge, scarce and expensive. Then comes the tiny flash storage, the crippled packages and the lack of many extra functions (missing packages).
I need a full-fledged Slackware system for what I'm usually up to...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
My gateway desktop will not load windows it stops after the gateway logo Jcayton General 5 06-07-2012 07:04 AM
normal default gateway reapperas with openvpn redirect-gateway jonnytabpni Linux - Networking 2 04-23-2009 02:11 PM
lm10.0 gateway is set but when I reboot I have to set the gateway rharvey32 Mandriva 8 02-13-2006 01:35 PM
What is a gateway? can I have more than one gateway on a vlan? abefroman Linux - Networking 3 09-06-2005 10:43 AM
Odd problem: Gateway unreachable after certain amount of time (Win XP Gateway) SocialEngineer Linux - Networking 2 08-13-2004 12:54 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 04:47 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration