SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
View Poll Results: I reviewed this proposal, and I think:
IMHO, as an rc.firewall is supposed (in any of the implementation I have seen) to start from a blank set of iptables rules, not with loading existing ones
Actually, rc.firewall is the script responsible for loading existing rules. Consider the rc.firewall generated by Alien Bob's firewall builder (see: Basic Security at docs.slackware.com). It loads an existing ruleset that is embedded in the script itself as iptables commands. My package's rc.firewall loads an existing ruleset from a separate .conf file, which is a trivial difference.
Quote:
Originally Posted by ponce
a call in rc.6 shouldn't be needed to save the existing rules
I agree. It's not needed. It might be useful to some Slackware operators and useless to others.
My package includes tools that update the running ruleset in real time. I detect intrusion attempts and immediately add the attacking IPs to an NFT address set used to drop packets. I also maintain a geofilter as a list of IP ranges, also in an NFT address set used to drop packets, and that gets dynamically updated once a month.
Because I am routinely updating the running ruleset in real time, it becomes highly useful to save the running ruleset at shutdown (and periodically in case of a crash), and restore it at startup. Again, not something that will appeal to everyone, but it does a great job for me.
I'm not a fan of the idea of automatically carrying firewall state over a shutdown/reboot. I'd rather see such things left as a manual operation so that no rules accidentally become persistent.
different custom rc.firewall from different sources might behave differently. Some of those scripts might not care about any arguments like "start", "stop", "restart" or "status" and regardless of argument only start the firewall again. Depending upon how the script is done it might be more or less bad to start it a second time.
I'm not a fan of the idea of automatically carrying firewall state over a shutdown/reboot
Yeah, that specific purpose is great for me but certainly not for everyone. I'm not proposing that -- I'm proposing rc.firewall stop should be called during shutdown, for packages or site operators to utilize as they see fit.
I think I covered this above -- (i) avoid manual steps (ii) this is a tangent. Probably I overshared what my first use of the shutdown hook would be, and created confusion about what I was asking for. The request is for the hook, not for the first use I have in mind for it personally.
I'm not sure I fully grasp this. I do understand that one of the difficulties remaining in SysV Init or any serial init system, centers around orphaned processes. It seems to me that once a network interface is stopped or disabled, iptables becomes something like an orphaned process, right? What I don't get is why that should ever be a problem even in a serial init system. It isn't the equivalent of the old "lazy write" issues is it?
You are right to say this, in the sense that an rc.firewall is not distributed, and there is only a hook provided in rc.inet2 to run it, if one gets created. So yes, you could say rc.firewall is not a "part" of Slackware. But the name exists as a hook in rc.inet2. What is missing is the analogous hook in rc.6. The proposed change to rc.6 would be an exact parallel to what rc.inet2 already does at startup.
During multiuser startup, rc.firewall, if it exists, is called as rc.firewall start by rc.inet2, just before any network daemons are started.
But it is not called during shutdown as rc.firewall stop.
In /etc/rc.d/rc.6 there is:
Code:
# Run any local shutdown scripts:
if [ -x /etc/rc.d/rc.local_shutdown ]; then
/etc/rc.d/rc.local_shutdown stop
fi
What am I missing that having code to handle the saving of the firewall rules could not be placed in /etc/rc.d/rc.local_shutdown, checking for the stop parameter if required? Local customisations are intended to be handled in /etc/rc.d/local and /etc/rc.d/rc.local_shutdown. I see no need for the proposed hook to be generally available.
PS - Slackware does not ship a rc.firewall script, but it does ship two basic firewall scripts from Roaring Penguin Software (firewall-masq and firewall-standalone in /etc/ppp/).
I cant speak for anyone else, but I suspect there would be others like myself who have scripted their own rc.firewall without checking for a start/stop argument, and the introduction of such a change would really wreak havoc.
I don't see the purpose in making the change for many of the reasons already mentioned. But if the change did occur, the only thing I'd ask for is a bunch of notice so it doesn't come about unexpectedly and catch me by surprise.
Any service/daemon that Slackware (optionally) starts, Slackware should stop on shutdown or reboot.
But the firewall start script for many users, perhaps most, is fundamentally different from many other init scripts in that it does not start a process or daemon in many cases, and may start a variety of processes in others.
For the simple cases where the script only uses iptables or nftables commands to add packet filtering rules into the Linux kernel there is literally nothing to "stop". This is a lowest common denominator use case and is probably the intended case handled by the inet2 script.
Those who start other processes from their firewall scripts almost by definition know how and when they may want to stop those processes and have provided a method for doing so.
The point being that there is no clear use case for a default stop condition.
Quote:
Originally Posted by GazL
I'm not a fan of the idea of automatically carrying firewall state over a shutdown/reboot. I'd rather see such things left as a manual operation so that no rules accidentally become persistent.
Absolutely!
You may want to save some state across system boot, especially with adaptive rules, but a simple iptables-save is far from a desirable default IMO.
Again, if you need to take some action at shutdown you probably already do so. If not, there is nothing useful to do and no clear use case for a default stop condition.
Last edited by astrogeek; 12-10-2022 at 10:27 PM.
Reason: stop condition
But the firewall start script for many users, perhaps most, is fundamentally different from many other init scripts in that it does not start a process or daemon in many cases, and may start a variety of processes in others.
Indeed. That is why /etc/rc.d/rc.inet2 (that runs /etc/rc.d/rc.firewall if executable) is called in /etc/rc.d/rc.M before any networked file systems are mounted. For most users it needs to run early and can be ignored without additional processing on shutdown.
once a network interface is stopped or disabled, iptables becomes something like an orphaned process, right?
If I understand your question right, the answer depends on what the installed rc.firewall does. If rc.firewall start does more than just load static rules, if for example it starts a process that updates rules in real time based on intrusion detection, then the call to rc.firewall stop would stop that process.
What am I missing that having code to handle the saving of the firewall rules could not be placed in /etc/rc.d/rc.local_shutdown, checking for the stop parameter if required?
If memory serves, I covered that at the top of the thread. Yes, that's what you should do for a locally written customization. But I'm developing a package. Manual edits around installation/removal of a package are sometimes a necessary evil. In this case, because the package supplies rc.firewall, and Slackware already has a startup hook for rc.firewall, a corresponding shutdown hook would avoid the manual edits.
Quote:
Originally Posted by allend
Slackware ... does ship two basic firewall scripts from Roaring Penguin Software (firewall-masq and firewall-standalone in /etc/ppp/).
Thank you for the pointer, I'll read them. I'm wondering because they are in a directory called /etc/ppp does that mean they are specific to PPP connections?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.