Deploying IPCop

IPCop is a firewall for the Small Office/Home Office (SOHO)
network, which is extremely easy to use. It provides most of the
basic features that you would expect a modern firewall to have, and
what is most important is that it sets this all up for you in a
highly automated and simplified way. It's very easy to get an IPCop
system up and running and takes hardly any time.

Trust Relationships between the Interfaces

The four types of network interface—Green, Red, Blue, and
Orange—supported by IPCop have differing levels of trust
associated with them. Here is a simple table outlining what traffic
is allowed to go to and from which interfaces. This table, and the
knowledge contained within it, should form the basis of our
planning when considering how many interfaces to use and what to
use them for. This is basically the Traffic Flow diagram from the
IPCop administrative guide.

Interface From

Interface To

Status

How To Access

Red

Red

Red

Red

Firewall

Orange

Blue

Green

CLOSED

CLOSED

CLOSED

CLOSED

External Access

Port Forwarding

Port Forwarding / VPN

Port Forwarding / VPN

Orange

Orange

Orange

Orange

Firewall

Red

Blue

Green

CLOSED

OPEN

CLOSED

CLOSED

DMZ Pinholes

DMZ Pinholes

Blue

Blue

Blue

Blue

Firewall

Red

Orange

Green

CLOSED

CLOSED

CLOSED

CLOSED

Blue Access

Blue Access

Blue Access

DMZ Pinholes / VPN

Green

Green

Green

Green

Firewall

Red

Orange

Blue

OPEN

OPEN

OPEN

OPEN

In visualizing the way in which traffic goes through the IPCop
firewall, we can see it as a sort of giant junction with a traffic
cop (literally, an IP Cop—hence the name!) in the middle of
it. When a car (in network parlance, a packet of data) reaches the
crossroads, the cop decides in which direction the packet should go
(based on the routing tables IPCop uses), and pushes it in the
appropriate direction.

In the case of a Green client accessing the Internet, we can see
from the previous table that this access is OPEN, so the cop allows
the traffic through. In other instances, however, this might not be
the case. If a Blue client tries to access a client on the Green
segment, for instance, the cop might allow the traffic through if
it comes over a VPN or through DMZ pinholes—but if a client
on the Blue segment has neither of these things explicitly allowing
the traffic, it is stopped. The car is pulled over, the occupants
victims of some virtual time in the cells!

Note that (generally) when we illustrate IPCop Configurations,
the Red interface is uppermost (North), the Orange interface is to
the left (West), the Blue interface is to the right (East), and the
Green interface is to the bottom (South).

Altering IPCop Functionality

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.

Topology One: NAT Firewall

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 a higher 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:

Green/Red zones

DHCP Server

DNS Server

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:

Intrusion Detection

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.

Topology Two: NAT Firewall with DMZ

In a small office situation with a growing company, the need for
incoming email might force the activation of the Orange zone, and
the deployment and installation of a mail server in this segment.
Such a company might choose to keep its Desktop and Internal Server
infrastructure within the Green network segment and put their
server in the DMZ on a switch/hub, or simply attached to the Orange
interface of the IPCop host using a crossover cable. As such
systems are exposed to the Internet, this segmentation provides a
considerable advantage by providing a 'stop line' past which it
would be harder for an intruder to escalate his or her access to
the network. Microsoft's Exchange mail server has for some time
supported such a configuration through the use of the 'front end'
and 'back end' exchange roles (although these roles will be
deprecated with future Exchange releases). With a different network
configuration however, such as Linux clients using a management
system such as Novell's eDirectory or RedHat's Directory Server
(RHDS), or a filtering appliance, a similar system with
externally-facing SMTP servers (perhaps running the open-source MTA
exim) would be equally beneficial.

In this topology, Clients are freely able to connect to the mail
server (whether via POP, IMAP, RPC, or RPC over HTTP). In order for
a mail server that exists as part of the network domain to
authenticate to the directory server, we would also need to open
the appropriate ports (contingent upon the directory provider) to
the directory server using the DMZ Pinholes feature.

We also have a Port Forwarding rule set up from the external IP
address of the IPCop firewall to port 25 on the mail server. This
allows external mail servers to connect to the mail server in order
to deliver email. In this topology, a compromise of the mail server
(which in the Green segment could compromise the entire network
segment) is controlled, as there is some level of protection
provided by the firewall.

In such a topology, we use the following capabilities of the
IPCop Firewall:

Red, Orange, Green zones

DMZ Pinholes

DHCP Server

DNS Server

Port Forwarding to Orange segment

We might also choose to employ any of the following elements of
functionality:

IPSec for remote access to Servers in the Green and Orange
segment or for external support

Back-end mail server with mailboxes in the Green zone, using
the Server in the Orange zone as a relay, performing anti-spam and
anti-virus scanning/filtering

Topology Three: NAT Firewall with DMZ and Wireless

In a larger organization, or if the network above grew, we might
choose to expand our network topology using one or more IPCop
firewalls.

Several IPCop firewalls might be used by such an individual in
order to separate several sites, or in order to further segregate
one or more DMZs with physically distinct firewalls. It is also
worth considering that IPCop is designed primarily for networks in
which it is the only network firewall, in the Small and Medium
Business, and Home/Home Office market. Although it is possible to
set IPCop up in larger deployments, this is fairly rare, and there
are other packages that are arguably more suited to such
deployments. In such circumstances, the constraints of IPCop's
network segmentation begin to be more burdensome than they are
convenient, and the amount of work required to tailor IPCop to meet
an organization's needs may exceed the work it would take to
manually set up another firewall package to suit the same
topology.

In this example, we will consider the broadest scope in which
one IPCop box could be deployed, using all four network interfaces
to protect a network with an internal (Green) network, an Internet
or WAN connection (Red), a DMZ containing more than one Server
(Orange), and a wireless segment (Blue) with an IPSec VPN system.
In such a situation, we would almost certainly choose to deploy all
of the higher-end features that IPCop contains, such as the Proxy
Server and the Intrusion Detection System.

In this situation, the services we are providing for individual
network interfaces are as follows: On the Red Interface, in
addition to the default firewalling policy, we are invoking the
Port Forwarding feature to allow connections to the mail server on
port 25 in the DMZ, and also to port 443 (https) on the mail server
in order to allow connections to the business webmail system. We
are also allowing incoming IPSec connections to the IPCop firewall
in order to allow remote access to staff who work remotely and to
provide remote connectivity for support purposes for the IT Staff
and third-party software and hardware vendors.

On the Blue interface, we are providing connectivity via an
IPSec VPN for clients in order that they can access services run
from Servers internally on the Green segment and DMZ segment.
Vendors and visitors are allowed access to the Green segment
through use of WPA in pre-shared key mode configured on the
wireless access point.

[ When using pre-shared keys make sure you use
the longest possible key combination straight from a good random source.
Even WPA cannot guard against the brute-forcing of weak keys. This
is also a fine reason for changing the pre-shared key
periodically. -- René ]

WPA-PSK with solely an access point prevents access to the
wireless segment and the Internet by unauthorized users, and is an
adequate solution for most small and medium networks; use of a
newer, WPA2-PSK-capable access point increases this security more
for those without an access point or network infrastructure
implementing RADIUS or Certificate Services. The firewalling policy
and IPSec system ensures that visitors/vendors only have access to
the Red zone (the Internet), and not to any of the resources on the
network.

On the Orange interface, our pinholes allow the DMZ servers to
connect to a directory server and Kerberos domain controller in the
Green segment in order to authenticate users logging onto them via
the company directory system. This ensures that the policy and
configuration for these Servers is managed centrally, and that
there are logs stored centrally for them, but the damage that could
be caused by a compromise of these externally-facing services is
greatly minimized, ensuring business security and regulatory
compliance.

On the Green interface we allow connectivity to all interfaces;
workstations and Servers within the Green segment are managed
service workstations on which users do not have the necessary level
of access to cause damage to the resources to which they have
access.

[ Trojans have become very popular. This a
good reason to think about restricting the networked
machine access inside the Green network to proxies equipped with
intrusion detection/prevention software. -- René ]

In such a situation, we are making use of the following IPCop
features:

Red, Orange, Green, Blue zones

DMZ Pinholes

DHCP Server

DNS Server

Port Forwarding to Orange segment

IPSec for remote access to Green, Orange, Blue segments

IPSec for access to internal resources by Blue users

Intrusion Detection System

Port Forwarding to web server on the Mail server
externally

Proxy Server (for desktop Internet access)

In a larger organization, we may also choose to use IPSec in
site-to-site mode in order to link this office with one or more
branch or parent offices. In this role, as in the role of a single
network firewall, IPCop excels.

This article has been adapted from the book, "Configuring IPCop
Firewalls: Closing Borders with Open Source" by Packt Publishing.

Barrie Dempster

Barrie Dempster is currently employed as a Senior Security Consultant
for NGS Software Ltd, a world-renowned security consultancy well known
for their focus in enterprise-level application vulnerability research
and database security. He has a background in Infrastructure and
Information Security in a number of specialised environments, such as
financial services institutions, telecommunications companies, call
centres, and other organisations across multiple continents. Barrie has
experience in the integration of network infrastructure and
telecommunications systems requiring high-calibre secure design, testing
and management. He has been involved in a variety of projects from the
design and implementation of Internet banking systems to large-scale
conferencing and telephony infrastructure, as well as penetration
testing and other security assessments of business-critical
infrastructure.

James Eaton-Lee

James Eaton-Lee works as a Consultant specializing in Infrastructure
Security who has worked with clients ranging from small businesses with
a handful of employees to multinational banks. He has a varied
background, including experience working with IT in ISPs, manufacturing
firms, and call centers. James has been involved in the integration of a
range of systems, from analogue and VOIP telephony to NT and AD domains
in mission-critical environments with thousands of hosts, as well as
UNIX & LINUX servers in a variety of roles. James is a strong
advocate of the use of appropriate technology, and the need to make
technology more approachable and flexible for businesses of all sizes,
but especially in the SME marketplace in which technology is often
forgotten and avoided. James has been a strong believer in the relevancy
and merit of Open Source and Free Software for a number of years and -
wherever appropriate - uses it for himself and his clients, integrating
it fluidly with other technologies.