Creating a lilo.conf and an initrd are both required just to get the system to boot. They are not the same thing as a firewall. The other scripts included in the installer/pkgtool are simple configuration tools that unambiguously select one option out of a finite number of options. A firewall cannot be represented by such a simple script/configuration and is a fundamentally different concept. For example, timeconfig allows you to set your timezone. There is really only one 'correct' answer to select. This is *not* the case with a firewall.

I will repeat that I wouldn't object to a firewall script being included, but pretending that it is a simple matter of shipping a do-everything script is not helping. Enabling a good, secure firewall *will* flood Pat with support requests asking why network services aren't working (why can't I ssh to my box???). Since the way to prevent those support requests is to get users to understand what they're doing, allowing users to implement their own firewalls via rc.firewall puts the responsibility on the user instead of the maintainer. I would much rather Pat spend his time juggling package versions and patches to try and get a good, stable, functional Slackware than worrying about writing firewall scripts and responding to e-mails from uninformed users, especially when there's a very good chance that I and anyone else looking for more than the bare minimum firewall will end up rewriting it anyway. Pumping out a stable distro and knowing which versions of software to include (for ~1000 packages) so that everything works well is beyond my capability and time constraints, but creating a firewall is well within my abilities. I would rather more time be spent on the former than the latter.

The EFG already exists (and is hosted on slackware.com) and is a noob-friendly way to create a firewall without any additional support required from Pat. I think it's sufficient. Of course that is just one man's opinion.

Also see this from rc.inet2:
Perhaps a note in Slackware-HOWTO or similar would officially document the 'hidden' rc.firewall capability and then no one would have an excuse for not knowing about it already.

Someone already pointed it out in an earlier post, but it was dismissed as being an arrogant comment by the next poster, while in fact it was a message which every Slacker should recognize:

After a Slackware installation, when you log in as user root (at that time, the only user account) you are greeted with "you have mail". If you take the time to actually read that mail, you will find the above quote in the email entitled "Welcome to Linux (Slackware 13.37)!" (the number will change with every new release).

I agree and this is why a firewall script should not be included IMHO.

Well there you go, no excuse. ;) Been a while since I read that (and while I did read the entire thread my poor memory deleted allend's post from my brain).

Going off what Eric said, the HOWTO documentation could be added to to include more information into this perhaps. That being said couldn't a sample firewall script be provided like the sample Samba script?

The sample Samba configuration file is included with Samba; it's just modified slightly in Slackware (adjusting the log/spool file locations).

I like the idea of a firewall included at set-up, but, I am fine with the way things are now. It is an interesting suggestion.

Just for a jape, I followed the documentation trail. The initial email to root says 'man iptables' for lots of information. Then the manual page for iptables gives a link to http://www.netfilter.org. At that site you can click on Documentation-HOWTOs with a collection of links in a section Tutorials. One of these links, titled 'Comparison of iptables automation tools' has this quote. I have added the emphasis.
I agree that a firewall is a necessary component of securing network services, but where do you draw a line with automation tools? Do you also want to introduce tools to automate setting up services like SSH, NFS, Samba? I do not think that any competent system administrator would contemplate this.

OK, let me rephrase that:
httpd service is "preconfigured" and is not required to get the system to boot.
same with sshd.

They have "sane" defaults and that is all that is being asked for a firewall config.

As mentioned earlier, the admin is totally responsible for enabling sshd AND firewall, as they should be disabled by default and are not needed for the system to function... so I don't see why the flood of "why can't I ssh into my box???" would happen.
Even if it did, it would happen because something YOU did, not the system.

Yeah I don't know about that...
 

I've installed *Firestarter* and *FW Builder* too. FW Builder is nice, and simple, and about as complex as you need it to be too.

Firestarter isn't updated that much, took quite a bit of work to install on one machine and is sorely lacking in the documentation department - not to mention the fact that you have to install well over a dozen deps leaving you with an almost GNOME ready box.

Patrick gave his two cents when he said taht following new installations he echo's ALL: ALL into hosts.deny as a starting point on a new box.

There's also the welcome email to root, and the rather unintuitively located /etc/ppp/firewall-standalone which doesn't work if simply copied to /etc/rc.d/rc.firewall and then chmod'd - At the very least one would need to know that they have to change $EXTIF to something along the lines of 'eth0' or 'wlan0'.

There was another thread with a different sort of firewall about a year ago here: http://www.linuxquestions.org/questi...script-884878/

Okay there's a lot of options. But then again, what kind of options are we really thinking about giving out?

A seasoned admin has his firewall scripts and mods them accordingly, experiments with new incarnations on sandboxes, and simply does a quick scp to /etc/rc.firewall and chmod's it 700.

A noob doesn't even know what an ICMP message is - it could take weeks for them to read through the instructions for what each port is for and for that matter, what a port is!

They might know what world of warcraft is (I know I don't), or minecraft (I don't know what that is either but I've built a couple of minecraft servers for my subscribers and it seems I'm hosting about 50 of them).

Heck, even asking a noob if they're going to be using eth0 or wlan0 is probably enough TMI to help them brick their machine - that they have to be asked whether they want sshd to start on boot is almost too much for many (as necessary a question as it is, it's not at all that obvious to us that this is a difficult question for most n00bs).

No. No firewall config included during installation - especially not dialogs for a Bash clone of Eric's EFG.

It's been pointed out in the threads above that we have FW Builder as an SBo, and that is good enough IMO as far as any sort of app is concerned.

We certainly don't want people asking themselves, "Gee. Firewall... I think I'm supposed to have one of those. I'll answer yes to that.", and then be presented in the middle of an install with a seemingly endless list of frightful questions that resemble a kernel makefile.

I do (Pat, if you're listening) think that the EFG should be mentioned in the welcome email with a link to it... Why?

• Because it's safe - in order to fsck things up you have to be able to gen the script and actually install it as rc.firewall
• Because it is an addtional learning tool that they can work with, read, glean wisdom from, and have something functional once they understand how to make it run.
• Because including a firewall generator as part of the standard Slackware install is inviting n00bs to fire off bug reports to LQ saying that their slackboxware macheen is broaken.

A mention of FW Builder at SBo, SBo in general, and sbopkg are probably also good things to cover as well in the welcome email, continuing in this same philosophy - Slackware gives you UNIX while you, the SA, make it what you want and need, and here's some kewl places to look for those tools.

All in all a firewall is just one of the first things that you *might* need/want to do w/your system. Installing an IDS is just as important in a forward facing box, and talk of including a question during the installation dialog as to whether you want to configure one of those is just as problematic a proposal.

That having been said, I think it's a great idea to clone Eric's EFG as a Bash script which has an SBo at Slackbuilds.org

Now, as far as truly important things are concerned, I think the automatic coffee maker script really should be included as part of the standard Slackware installation process IMNSHO ;)

I hope that helps!

Kindest regards,

.

But i really do like the idea of setting up everything by hand. I'm sure, Slackware is not that kind of Linux distribution which must have tools like ufw. The beauty of Slackware is being Unix-like, oldschool and so on.
In Slackware I advice you to use this script:
Name it rc.firewall and put in in /etc/rc.d/ directory. Then make it executable (chmod +x /etc/rc.d/rc.firewall)
It will start with the system automatically*. And you will be able to use these commands:
... to start / stop / restart your firewall rules set manually.

*If you look through /etc/rc.d/rc.inet2, you will find there:
This is how the work is done :-)

httpd.conf is shipped with apache. It is slightly modified to make it obey Slackware's directory setup and adds a few commented lines to make it easier to enable PHP support for noobs. The file itself, however, comes from apache. openssh's ssh_config and sshd_config files are shipped by default with ssh and are not Slackware-specific (and shipping with root logins enabled is hardly a sane default). In both httpd and ssh the only real modification is the inclusion of an rc.httpd and rc.sshd script to get them to start in Slackware's BSD-style SysV init system. Obviously rc.firewall is already setup for this. It is easy to warp facts to support your own ideas but once again, rc.firewall is showing remarkable consistency with regards to the rest of Slackware's settings. Perhaps if you could get upstream iptables to produce a default firewall configuration all would be fine. :rolleyes:

Again, Pat/Slackware is not the creator of most 'sane' defaults -- it ships upstream defaults and modifies them only if they will cause trouble (if they won't start, or if they will spam the root directory). Since there is no upstream firewall script, and rc.firewall is already set to start if available, there is no need for modification.

The one thing we do have as a problem as stated is the firewall script provided at /etc/ppp/firewall-standalone is not readily deploy-able even as a sample script. Having a sample script that can be universal to everyone out-of-the-box, even in the minimum, provided can be a great learning tool to have for those wanting to learn, for the rest of us who already have our pre-built scripts, do we need it? No. Can we edit the default out? Yes we can.

1. Are we asking to consider for a prebuilt Firewall to be included with Slackware ready to go out of the box?

No, we are asking for a sample script that can be edited, copied, and then made executable with universal defaults to anyone, regardless of skill level, can work with.

2. Are we asking to consider for an nCurses tool to be added into Slackware's setup?

ONLY if it can be skipped during installation if we so chose to.

3. Are we asking to consider for more packages for bloatware to the system?

No we aren't. In fact we are asking to AVOID having to add extra packages to the system like FWBuilder, FireStarter, etc. With sample scripts we don't need extra packages.

4. Are we asking to consider for some extra documentation like a Firewall-HOWTO?

While a lot of information exists online, getting that information if you are offline is rather problematic especially when most of it is written in tech jargon, and not English when you aren't a tech speaking person new to Linux. Newbies (not nOObs) often need an easy to follow guide so they can learn. Slackware's already included HOWTOs are easy to follow, written in English, and are simple enough for anyone.

Besides, Slackware already teaches the best fundamentals of Linux compared to any other distribution outside of Linux From Scratch, so why not teach those willing to learn for themselves how to properly setup a basic universal firewall and provide a proper sample thereof for beginners to start with and expand from?

When I installed Slackware, the first time and every consecutive time, I used Slackbook. I would recommend everyone to do so. It's needed if you intend to use Slackware, that's what it's about, thorough reading. There's a good chapter about Iptables in the Slackbook. Maybe a reference to Alien Bob's generator will do. It's not a Slackware-installation matter, it's a Slackbook matter.

It seems to me that firewalls are very unique and particular to each network. I don't know if there are "universal defaults" besides a deny-all type of script. I still think any sample script is going to cause headaches for Pat because once people start uncommenting lines or modifying their setup, and then locking themselves out of their box, they're going to complain to Pat and take up valuable time.

Teaching people the fundamentals of Linux is very different from teaching people the fundamentals of iptables. I see Slackware as a building block -- a distribution intended to give people a solid foundation on which to learn themselves. Emphasis on the "themselves." The whole teaching a man to fish kind of thing.

Besides, this teaching thing is a slippery slope. You ask that Pat include a basic firewall to teach people some fundamentals. Is he supposed to teach them about NAT or port forwarding? Where does it end?

As stated by others far more eloquently than I, I would prefer Pat spend his limited time on creating this solid building block -- i.e. packaging, making sure all the nuts and bolts fit together, etc. -- than spending his time teaching people iptables.

But that's just me.