Excerpt from the book "Configuring IPCop Firewalls: Closing Borders with Open Source"
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 its 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
Port Forwarding to Orange segment
We might also choose to employ any of the following elements of functionality:
Intrusion Detection System
Port Forwarding to web server on the mail server (for external access of IMAP or Exchange mailboxes via a webmail solution such as Horde, SquirrelMail, or Outlook Web Access) Proxy Server (for desktop Internet access)
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
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.
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, as 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.
In such a situation, we are making use of the following IPCop features:
Red, Orange, Green, Blue zones
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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide