Debian Administration

While it's true Shorewall is used for the firewall configuration in my tutorial, only 2 of the current 12 (and growing) steps in the guide actually relate to working with Shorewall (while every step uses Debian). It's intended to be modular, so even if you skipped Shorewall entirely, any of the network services topics should still be relevant.

Good to know it actually works!

Thanks again for pointing out the typo, those silly config files don't spellcheck as well as the rest of the document. :)

Well there are two (partially related) reasons. First, if you notice, I had already mentioned this fact briefly in the DHCP alternative alert. :) More importantly though:
1) The tutorial is intended to be modular, so ideally one part shouldn't influence another part, and parts can be skipped based on the reader's needs. And assuming one is running DHCP but skipping the DNSMasq chapter, installing DNSMasq soley for DHCP may or may not make much sense.
2) Furthermore, the tutorial is less about "this is how it should be done" and more about "this is how it can be done." In that sense, I feel I'm doing the reader more of a service by covering a broader range of popular, available software. There's no doubt the regular DHCPD package is basically the standard, so I felt it was important to cover it to some degree. Now that both packages have exposure in the tutorial, the reader can make a more informed decision about what they want based on their own experience.

Thanks for the feedback!

-
Matt

That is correct. Furthermore, you don't need to apply the entire firewall configuration there... You basically only need to name your interfaces and set the policy, the parts relating to NAT/PAT are unnecessary and should be skipped on a host machine. The Shorewall website has some great documentation, I recommend further reading there.

-
Matt

And that was me. Forgot to log in. :-/

It's true that any server anywhere can be a liability if not properly configured and maintained. With firewalls it's mostly a matter of exposure. For example in my tutorial (as I recall, somebody catch me if I'm wrong), I haven't encouraged a single service to be made available on the internet side of the firewall. If access is only allowed from the LAN, and you trust people on the LAN completely (yourself or mom and pop per se), then there's as little risk as you're ever going to see no matter what services are running. The key is blocking the incoming traffic from risky zones like the internet, and the firewall handles that.

On the other hand, if you're working in a business environment, you can't necessarily trust the people on the LAN either. The fact remains you will probably have to run some of these services, but to minimize risk you can choose to run them on separate machines with totally separate authentication. For example separate machines for DHCP and DNS. If one service were compromised, hopefully the others would be unaffected.

Keep in mind, however, that there's no such thing as perfect security without proper maintenance. A firewall with no services can be compromised if an operating system flaw is found and not patched by the administrator, and this is true of any operating system. By the same token, any system with exposed services (a server) can be perfectly safe if diligently maintained. So while there are best practices, such as dividing tasks amoung separate physical machines, it usually comes down to proper planning, configuration, and maintenance to make the difference between a safe network and a compromised network.

-
Matt

Well static IPs are really no problem for the tutorial configuration. It should only require the following modifications, give or take some tweaks:

In the Debian interfaces config, configure both interfaces with their static IP addresses, rather than using DHCP to configure the ISP side.

You can skip the step for a DHCP server entirely if you're using static IP addresses on all your internal hosts. Granted this method isn't usually recommended if for no other reason than configuring 25+ boxes individually would be a major pain...but there's no technical reason you can't do it. Just set your firewall's internal interface as the default gateway on all the internal machines, and make sure none of their IPs conflict, and that is all that's required to make them compatible.

The shorewall error sounds like something that would happen where there's a typo in one of the configs. Did you run "shorewall check" to see if it finds an error? If so, do this from the command line first. If that passes, run "shorewall start" (or "restart") from the command line, rather than using the init script. This should start shorewall in the foreground and allow you to see which config is causing a problem. You can also check /var/log/syslog for the shorewall errors. If you find it was caused by an problem in the tutorial, please let me know.

-
Matt

It is indeed... keep in mind it was written for Debian Sarge and has not yet been updated for Etch.