Excerpt from the book "Configuring IPCop Firewalls: Closing Borders with Open Source"
As with many aspects of the behavior of the IPCop firewall, it is possible to alter the behavior of the firewalling rules in order to customize IPCop to meet a topology un-catered for by the default rules. Within the context of the firewall rules, IPCop has had a file since the 1.4-series release that allows users to specifically add their own firewall rules (/etc/rc.d/rc.firewall.local). Since version 1.3, there have been iptables chains, CUSTOMINPUT, CUSTOMFORWARD, etc., allowing iptables rules to be added manually.
Specifically using iptables is out of our scope here, but we recommend that interested readers read:
The Linux iptables HOWTO at www.linuxguruz.com/iptables/howto/
Our first topology exists as a drop-in replacement for the many NAT firewalls that exist in the market. In small offices and homes, solutions such as the embedded NAT firewalls sold by D-Link, Linksys, and friends are frequently deployed in order to provide small networks with cost-effective Internet access. Solutions such as Internet Connection Sharing, a combined NAT firewall, DNS Proxy, and DHCP Server, built into client editions of Windows since Windows 98, are also frequently used in order to allow one PC with a modem or network interface to act as a network gateway for other clients. For our purposes here, we will consider ICS, as such a topology with ICS is effectively a superset of the work required to replace a router such as a Linksys or NETGEAR model as mentioned previously. Our migration from one of these routers to IPCop would be identical save for the decommissioning of the ICS software on the client -- if we remove the router, this is unnecessary and the router can be left configured as-is (and/or kept as a backup, or reused elsewhere) (See http://www.annoyances.org/exec/show/ics for more information on implementing (and consequently, decommissioning) ICS on different Windows versions).
Such solutions, while cheap and convenient, are often not scalable or reliable, and provide poor security. They open workstations up to unnecessary security risks, provide limited throughput, and are often unreliable, requiring frequent reboots and locking up.
As with software firewalls, a network firewall is designed as a barrier in between your workstations and the Internet. By connecting one of your workstations directly to the Internet and using a solution like ICS, although you reduce the resources required to share the internet connection, you expose that workstation to unnecessary risk. There is also an obligation for that PC to be on all the time -- compared to a low-end PC with no unnecessary components and a low-power PSU running IPCop, this may be noisier, and have more power consumption.
IPCop offers a cost-effective replacement in such situations, providing small businesses and home users with a powerful firewall without the need for over-complexity, and adding other features not present in embedded solutions or ICS, such as a customizable DHCP Server, Intrusion Detection, a Proxy Server, and so on.
Such a topology ensures that firewalling is done before data gets to clients, using a package designed to act as a network firewall, greatly increasing the quality of service to clients as well as the security that their network offers. In this situation, the components of IPCop in use would be:
In such a situation, a network administrator or consultant might also choose to enable any of the following pieces of functionality in order to enhance the services provided to the network:
IPSec in order to allow remote work or remote support
Port Forwarding in order to allow remote access to VNC or Terminal Services/Remote Desktop for a simplified model of remote access for remote support (more convenient than IPSec although inherently more insecure)
Decommissioning of ICS in such a situation is quite simple -- we would merely disable the ICS functionality, as depicted in the following screenshot (taken from the network connections property of the external, internet-facing ICS network interface).
Removing ICS is as simple as deselecting the Allow other network users to connect through this computer's Internet connection option. After we have done this, we should hit OK, reboot if asked to, and then we are free to disable and/or remove the external interface on the workstation (disable if we wish to leave a second network card in the machine or if it has two onboard cards, or remove if we are using an external modem or other piece of hardware we intend to remove or install in our IPCop host).
Firewall rules for this topology are simple; as the Green segment is automatically allowed to access resources on the Red interface, there is no topology-specific setup required in order to set this up.
Another substantial benefit in deploying IPCop for such a small office situation is that in the event that the business is required to grow, the solution that it has is scalable. Such a business running a handful of Windows workstations in a workgroup may decide that a workgroup is insufficient for its needs and that it requires centralized management, file storage, and configuration.
IPCop, even in a pre-upgrade scenario like this, is advantageous simply because it provides a built-in, open upgrade path. There is no hardware or software upgrade required to move from simple NAT and DHCP to a network with several network segments, port forwarding, and a proxy server. If the Server already has several network cards (and with the price of these nowadays, there's no reason for it not to, if an expansion is anticipated), this can even be done with little or no noticeable interruption in service to existing clients.
Webinar: 8 Signs You’re Beyond Cron
On Demand NOW
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.View Now!
|diff -u: What's New in Kernel Development||May 06, 2015|
|Chrome-Colored Parakeets||May 05, 2015|
|Mumblehard--Let's End Its Five-Year Reign||May 04, 2015|
|An Easy Way to Pay for Journalism, Music and Everything Else We Like||May 04, 2015|
|When Official Debian Support Ends, Who Will Save You?||May 01, 2015|
|May 2015 Issue of Linux Journal: Cool Projects||May 01, 2015|
- diff -u: What's New in Kernel Development
- Mumblehard--Let's End Its Five-Year Reign
- Chrome-Colored Parakeets
- An Easy Way to Pay for Journalism, Music and Everything Else We Like
- When Official Debian Support Ends, Who Will Save You?
- Ubuntu Ditches Upstart
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Picking Out the Nouns
- Return of the Mac