LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
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-02-2019, 02:12 PM   #46
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Original Poster
Rep: Reputation: Disabled

Quote:
for that you can have a look at this
Thanks. I'll look at ntop when the time arrives, but the web site is the usual JavaSh_t POS. Typically that is how I make my first impression of a software project.

Looks like a built-in web server so perhaps I would not have to install Apache.

At work we use cricket and nagios. Cricket? Yeah, I know -- hasn't been updated in 15 years (roll eyes). Not my decision to control or change. Anyway I am familiar with that but I never was warm about nagios.

Quote:
Cacti could also qualify:
Quote:
And if you like to get your fingers dirty, you could use MRTG.
Looks interesting. Both on slackbuilds.org so that is a decent start. MRTG seems dedicated to routers, which seems more in tune to this project. One challenge is I'm not good at snmp.

Last edited by upnort; 09-02-2019 at 02:18 PM.
 
Old 09-02-2019, 02:21 PM   #47
TristanT
LQ Newbie
 
Registered: Jul 2018
Distribution: Slackware, Debian
Posts: 4

Rep: Reputation: 16
You can run node_exporter on the network device, and then let Prometheus fetch and store the metrics. To visualize the data you can use Grafana.

Granted it might be overkill for a simple setup, especially if all of the aforementioned tools are new to you. But look at those shiny graphs!!
 
Old 09-02-2019, 02:28 PM   #48
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Original Poster
Rep: Reputation: Disabled
Quote:
But look at those shiny graphs!!
Yup. I'm familiar with the software but never had a reason or need to explore.
 
Old 09-02-2019, 02:56 PM   #49
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
MRTG seems dedicated to routers, which seems more in tune to this project. One challenge is I'm not good at snmp.
MRTG was "the tool" everybody was using a long time ago, there was simply no alternative and don't worry, nobody is good with SNMP and that thing isn't Simple. I wish I could help you with more info on how to use MRTG, but I'm afraid it's lost knowledge for me and I'm also unable to find any notes from my previous telco "non-enterprise" experience (in enterprises there are usually "enterprise level" solutions employed and nobody plays with MRTG).

I mentioned in a previous post that I'm using monitorix now, it's simple, compact, lightweight, flexible, doesn't require a web server and the predefined graphs are enough for my monitoring needs. On the networking part it's able to graph per interface/per port(service)/per protocol, etc., but not per IP AFAIK (it could be possible).
Here you have a short review:
https://www.tecmint.com/monitorix-a-...ool-for-linux/
And you could grab it from SlackBuilds (it requires rrdtool):
http://slackbuilds.org/repository/14...tem/monitorix/

P.S. MRTG examples with the help of scripts (for gathering info) - without SNMP & with the help of iptables:
https://edge2.blogspot.com/2013/11/m...hout-snmp.html
https://benctechnicalblog.blogspot.c...cord-ipv4.html
https://www.techrepublic.com/article...and-firewalls/
..etc - just search the net, plenty of good info

Last edited by abga; 09-02-2019 at 03:15 PM. Reason: P.S.
 
Old 09-02-2019, 03:35 PM   #50
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Original Poster
Rep: Reputation: Disabled
Quote:
in enterprises there are usually "enterprise level" solutions employed and nobody plays with MRTG
For me, that is a reasonable clue. If the big shots aren't using a certain software then I want to know why. Often one reason is scalability. That does not apply to small business and home users, but other common reasons are the software is not well maintained, is not current with other technologies, etc. One reason is arrogance too (not cool and shiny anymore).

Quote:
I mentioned in a previous post that I'm using monitorix now, it's simple, compact, lightweight, flexible, doesn't require a web server and the predefined graphs are enough for my monitoring needs. On the networking part it's able to graph per interface/per port(service)/per protocol, etc., but not per IP AFAIK (it could be possible).
I have monitorix in my planning outline. I added the other tools too. For rudimentary basic monthly bandwidth cap monitoring I can use vnstat, which I have been using in the LAN for some years. As this device would be a gateway, the statistics would reflect that easily. No cute, shiny web page graphs, but in the beginning of this project that will not be a show stopper.

While nice shiny graphs are desired, I also want to create something like a Conky desktop output. I will be running the system without X. After the prototyping stage headless too. I don't know how these other network monitoring tools might work as a Conky alternative. Likely I will have to use a combination of tools and scripting to obtain and display something similar to a desktop Conky. I haven't yet decided where I will display this data. Probably a LAN side web server. Nothing fancy.

Last edited by upnort; 09-02-2019 at 03:37 PM.
 
Old 09-02-2019, 03:59 PM   #51
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,211

Rep: Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640
The monitoring tools we discussed are all generating html reports and you'll need X and a browser to visualize them. You could automatically launch X and a stripped down browser window loading the stats page.
Some inspiration:
https://linuxconfig.org/how-to-run-x...esktop-or-a-wm
https://superuser.com/questions/2195...window-manager

A Conky alternative (graphical) would need X too I guess.

Without X, just text mode, there are some ncurses based monitoring tools that you could use, iptraf-ng - LAN station monitor - being one of them.
 
1 members found this post helpful.
Old 09-02-2019, 04:08 PM   #52
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Original Poster
Rep: Reputation: Disabled
Quote:
and you'll need X and a browser to visualize them.
Yes, from a client system, but not on the gateway device/server. Likely all I need is a bookmark to open the page located on the gateway system, just like any web server. I just need to decide on a way to collate the information into a format I want.
 
Old 09-02-2019, 04:15 PM   #53
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,211

Rep: Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640Reputation: 640
Sorry I was under the impression that you'd like to display the stats on the gateway itself - that's by reading the last section of your post #50
On the client you could permanently display the stats html as your desktop background. Again, some inspirations:
https://superuser.com/questions/4191...paper-on-linux
 
Old 09-21-2019, 12:14 PM   #54
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Original Poster
Rep: Reputation: Disabled
Quote:
I have a little mini-ITX AMD E-350 system as my router. It has *one* ethernet port.
It has *24* network interfaces.
Do you mean IP aliasing (eth0:0, eth0:1, eth0:3, eth0:4, etc.)? Might be a way to avoid additional physical NICs with VLANs.
 
Old 09-21-2019, 01:07 PM   #55
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,672

Rep: Reputation: Disabled
Quote:
Originally Posted by upnort View Post
Do you mean IP aliasing (eth0:0, eth0:1, eth0:3, eth0:4, etc.)? Might be a way to avoid additional physical NICs with VLANs.
No, he said he's using VLANs. He's created a number of VLAN interfaces with vconfig, and they all use the underlying physical i/f as an 802.1Q VLAN trunk to a switch, which in turn has ports that are members of the different VLANs corresponding to the VLAN interfaces on the firewall.

I'm doing the exact same with VIA-based mini-ITX boards in 1U enclosures. The boards have two physical interfaces; the (Slackware-based) firewalls have anything from 5 to 60+ interfaces serving different subnets.
 
2 members found this post helpful.
Old 09-21-2019, 01:53 PM   #56
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Original Poster
Rep: Reputation: Disabled
Quote:
he said he's using VLANs. He's created a number of VLAN interfaces with vconfig
OK. Seems this will still help to avoid multiple physical NICs.

Quote:
The boards have two physical interfaces; the (Slackware-based) firewalls have anything from 5 to 60+ interfaces serving different subnets.
Are you able to share some (sanitized) firewall snippets?

Last edited by upnort; 09-21-2019 at 01:55 PM.
 
Old 09-21-2019, 05:55 PM   #57
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,672

Rep: Reputation: Disabled
Quote:
Originally Posted by upnort View Post
Are you able to share some (sanitized) firewall snippets?
OK, you asked for it.

I've spent quite a bit of time trying to figure out what might be the ideal structure for a firewall script. So far I've concluded that:
  • a firewall script should be written in such a way that it can be re-run at any time to reapply or alter the ruleset, and
  • variables should obviously be used for references to interfaces, networks, IP addresses etc.
My scripts start with a section defining relevant interfaces:
Code:
ext_if=eth1
int_if=eth0.16
dmz_if=eth0.17
I fetch the IP addresses from the interfaces using shell commands:
Code:
ext_ip=$(ip -4 addr show dev ${ext_if} \
               | grep inet \
               | sed -e "s/.*inet //" -e "s/\/.*//")
Then follows a section where I make sure the relevant NAT/conntrack modules are loaded with modprobe. Since running modprobe twice does no damage, I just pipe all errors to /dev/null.

In some cases, module parameters may be needed. For instance, I've found the default size of the xt_recent IP list a bit too small for my liking. I prefer to add such parameters to a .conf file in /etc/modprobe.d/ rather than embedding them in the firewall ruleset, but I often add a comment above the relevant modprobe command describing the required parameter and why it's needed:
Code:
# note: the following option should be added for xt_recent to
# make sure we can keep track of all bots trying to brute-force
# the SSH and SSTP services:
#  option xt_recent ip_list_tot=5000
modprobe xt_recent 2>/dev/null
The next section consists of four commands adding two specific, temporary rules to the top of the INPUT and FORWARD chains:
Code:
iptables -I INPUT 1 -i lo -j ACCEPT
iptables -I INPUT 2 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 1 -i lo -j ACCEPT
iptables -I FORWARD 2 -m state --state ESTABLISHED,RELATED -j ACCEPT
The idea here is to keep the firewall/router operational while the real ruleset is being flushed and replaced. With these two rules in place, I can clear the existing ruleset by repeatedly deleting rule #3 in both chains until an error occurs:
Code:
while iptables -D INPUT 3 2>/dev/null; do : ; done
while iptables -D FORWARD 3 2>/dev/null; do : ; done
If the firewall script contains custom chains, I also add commands to the above section to delete these. I usually flush the PREROUTING and POSTROUTING chains of the nat table here as well.

Then follows the real ruleset.

If the administrative/security policy allows it, I almost always use an "implicit deny" approach, where I explicitly allow any traffic that is to pass through the firewall and drop everything else. I also try to design the ruleset in such a way that the most common traffic gets caught as high up as possible in the ruleset, so in some cases I add what might seem to be superfluous DROP rules rather than letting the final, implicit DROP handle a packet.

I usually start off with two rules identical to the temporary rules above, handling loopback traffic and established/related traffic respectively. This is by far the most efficient way to process packets for active connections, but security-wise there's a slight trade-off (more about that below).

Then follows various sections that handle:
  • input rules (to the firewall itself, including rate limiting to block bots running brute-force attacks)
  • port forwarding (a DNAT rule in PREROUTING and a corresponding ALLOW rule in FORWARD)
  • general forwarding rules
  • NAT overloading
...usually in that order.

<slight_digression>
In my earliest attempts I tried to organize the rules according to the table and chain in which they belonged (keeping, say, NAT and FORWARD rules separate), but I quickly abandoned that approach as it maps very poorly to the administrative policy rules a firewall ruleset is meant to implement.
</slight_digression>

At the very end of the script I just have to delete the four temporary rules I added at the top of the script:
Code:
iptables -D INPUT 1
iptables -D INPUT 1
iptables -D FORWARD 1
iptables -D FORWARD 1
As for the security issue I alluded to above:

The main disadvantage I see with this approach, is that due to the general nature of the established/related rule at the top of the chain, active connections are never dropped even if a change in the ruleset prohibits new connections of a given type. A client could in theory keep such a connection open forever.

For established connections this could be rectified by replacing the general rule with a number of specific "ESTABLISHED" rules for each and every TCP and UDP port. This would greatly increase the size of the ruleset and might have a negative effect on performance. However, this approach can not be applied to related connections, since it's usually impossible to know which port numbers such secondary connections are using.

The proper solution (to both) would be to parse the conntrack table and terminate any active connections that no longer have a matching INPUT or FORWARD rule. I'll get around to doing that eventually... I think. Maybe.

Regarding the various rules that would be needed to allow outbound traffic from multiple zones in an "implicit deny" setup:

I often take advantage of the fact that the Slackware firewall ruleset is just a bash script, and make liberal use of loops when many interfaces and/or ports are involved:
Code:
# taken from an existing script and modified, but entirely untested:
tcp_outbound_allowed="53 80 110 143 443 587 993 995 3389 10000"
source_interfaces="$int_if01 $int_if02 $int_if03 $int_if04 $int_if05 $int_if06"
for $tcp_port in $tcp_outbound_allowed; do
  for $interface in $source_interfaces; do
    iptables -A FORWARD -i $interface -o $ext_if -p tcp --dport $tcp_port -j ACCEPT
  done
done
In environments where there's a risk of, shall we say "creative" users (guest WiFi networks, educational establishments etc), I usually add a command to extract the IP address and netmask from the input interface in order to add a "-s <ip address>/<CIDR>" parameter to the rule above, which would block IP spoofing attempts. I usually put in some rate limiting rules as well.

For the time being, I use separate files for the IPv4 and IPv6 firewall ruleset. I do this because even if I intend to allow the exact same types of traffic for both protocols, there will invariably be some differences between the rulesets due to factors such as NAT. For now, I just stick all IPv6 rules in a file called /etc/rc.d/rc.firewall6 which I then source at the bottom of rc.firewall.

Last edited by Ser Olmy; 09-21-2019 at 05:58 PM.
 
2 members found this post helpful.
Old 09-21-2019, 07:41 PM   #58
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
I've spent quite a bit of time trying to figure out what might be the ideal structure for a firewall script.
KISS always rulez. Set the policies on DENY (you already mentionrd that) and only care&handle the traffic you need, keep the ruleset low and the CPU happy.
Quote:
Originally Posted by Ser Olmy View Post
Then follows a section where I make sure the relevant NAT/conntrack modules are loaded with modprobe. Since running modprobe twice does no damage, I just pipe all errors to /dev/null.

In some cases, module parameters may be needed. For instance, I've found the default size of the xt_recent IP list a bit too small for my liking. I prefer to add such parameters to a .conf file in /etc/modprobe.d/ rather than embedding them in the firewall ruleset, but
Required modules will be automatically loaded by iptables (ip_tables). Loading iptables modules manually makes sense when overriding default parameters values is needed, like in the case described (I'm happy with the defaults, never bothered).
Quote:
Originally Posted by Ser Olmy View Post
The next section consists of four commands adding two specific, temporary rules to the top of the INPUT and FORWARD ...
...
At the very end of the script I just have to delete the four temporary rules I added at the top of the script
Way too complicated for me to follow

If you're into extensive scripting and over-complicating your firewall, I guess nftables might be of interest:
https://wiki.nftables.org/wiki-nftab..._with_iptables
 
Old 09-21-2019, 08:10 PM   #59
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,672

Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
KISS always rulez. Set the policies on DENY (you already mentionrd that) and only care&handle the traffic you need, keep the ruleset low and the CPU happy.
That's a good rule of thumb. Also, it's precisely what I'm doing.
Quote:
Originally Posted by abga View Post
Required modules will be automatically loaded by iptables (ip_tables).
Have you noticed that occasionally, automatic module loading introduces a small delay? And sometimes, this delay causes the command in question to report failure, even though it actually succeeds? That's why I'm loading modules manually.
Quote:
Originally Posted by abga View Post
Way too complicated for me to follow
I assume that was a joke.
Quote:
Originally Posted by abga View Post
If you're into extensive scripting and over-complicating your firewall, I guess nftables might be of interest:
https://wiki.nftables.org/wiki-nftab..._with_iptables
I would argue that when one's task is to configure a multi-zone firewall in order to implement a security policy, a certain level of intricacy within the solution may in fact be unavoidable.

The best way (IMHO) to handle such problems, it to create a framework that can provide the required functionality and is reasonably easy to read and understand, while simultaneously providing a decent level of extensibility and flexibility. Hence my attempts at creating a template for a firewall script.

As for your reference to nftables, I'm not quite sure what your point is. nftables is just the next generation Linux firewall, which provides its own set of tools and configuration files. We've been through similar changes several times in the past (ipfwadm -> ipchains -> iptables).

I guess I could run every iptables command in my script through the iptables-translate program to obtain the new syntax, but I don't see how that would affect the complexity of the firewall setup in the slightest.
 
Old 09-21-2019, 08:53 PM   #60
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
I would argue that when one's task is to configure a multi-zone firewall in order to implement a security policy, a certain level of intricacy within the solution may in fact be unavoidable.

The best way (IMHO) to handle such problems, it to create a framework that can provide the required functionality and is reasonably easy to read and understand, while simultaneously providing a decent level of extensibility and flexibility. Hence my attempts at creating a template for a firewall script.
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" complex firewall and ... a single point of failure. Even in my simple home setup I have 2 GW (top one is also doing VLANs) and 3 firewalls (including local) between my system (so called "work LAN") and the outside. And there's more, but I cannot tell you because then I'll need to shoot you

I noticed you like scripting things and I suggested nftables, considering it easier to use compared to iptables, nothing more.
 
  


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:02 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