Creating A Linux Firewall Using the TIS Firewall Toolkit
Obtain the toolkit, Linux patches, and, if desired, the S/Key package, as detailed in Obtaining Firewall Resources. Bellcore's S/Key provides one-time password support for network authentication if built into the toolkit. A number of commercial one-time password systems are also supported by the fwtk, but their use is not detailed in this article.
Put the fwtk archive in /usr/src/, and run tar xfz fwtk-v1.3.tar.Z to unpack it. If you prefer to build in a different place, modify the Makefile.config as appropriate. The Linux patches that we will be applying assume /usr/src/fwtk is the source code directory.
These patches are based on the work of Marco Pauck (firstname.lastname@example.org) and the firewall-users mailing list. In addition, there are some modifications and additions done by the author to allow the x-gw proxy to work and to support the S/Key authentication mechanism. Most of the patches work around Linux's select() function. Put the fwtkpatches.tgz file into /usr/src/fwtk. Then run tar xfz fwtkpatches.tgz which will create a patches directory. Go into the patches directory and run the INSTALL script or apply the patches by hand. If you do not want S/Key support, run the INSTALL.noskey script instead.
Assuming you want S/Key, put the S/Key archive in /usr/src and run tar xfz skey-2.2.tar.gz to un-archive it. It is necessary to compile S/Key first so that its libraries can be linked into the authentication service when we compile the fwtk. This S/Key is already ported to Linux, so all that is necessary to build it is to run make inside the /usr/src/skey-2.2 directory.
When the patches have been installed and S/Key has been compiled, you can modify the Makefile.config if you want to change any of the defaults, but the rest of this article will assume you have left the Makefile.config as patched. Go to /usr/src/fwtk/ and run make and make install. The firewall components will be installed in /usr/local/etc/ by default.
The firewall toolkit is made up of three main components: netacl, authsrv, and the various service proxies. Netacl is similar to the tcp wrapper, tcpd, that is common on many Linux systems. Netacl is used to check rules on a per-service basis and take the defined action. You edit your /etc/inetd.conf file to call netacl, passing the normal service to netacl as its first parameter. An example entry for the finger service might look like Listing 1. inetd will invoke netacl when a connection is made on the finger port.
Netacl looks in the common configuration file to see what action to take. The common configuration file is called the netperm-table and is found in /usr/local/etc/netperm-table. A default netperm-table that has many examples, in addition to the ones presented in this article, is installed automatically. Netacl looks in the netperm-table and reads entries that start with netacl. Netacl understands the permit-hosts and deny-hosts options for defining access lists and requires -exec to be defined for each line as well, as shown in Listing 2.
A given service can have multiple lines of both the permit and deny varieties. Address can be a list of hosts addresses, and wildcards such as *.my.domain or 129.17.* are supported. The keyword unknown matches hosts that cannot be resolved using DNS. The first rule that matches is the one performed. Lines may not be broken.
In the examples given in this article, the following conventions will be used: .internal.net will represent your internal network. ftp.server.internal.net will represent a ftp server internal to your network. www.server.internal.net will represent a www server internal to your network. compute.server.internal.net is a compute server internal to your network. trusted.external.net is an external network that you trust. bastion.host.internal.network will represent your bastion host's IP address.
An important point is that these rules are not associated with a network interface. If you write rules for a service to allow your internal private network to have special access rights, you must ensure that those IP addresses could only have been received from your internal network. IP spooling can be used to pretend to be a host on your internal network and take advantage of your rules. This can be prevented by using screening routers to block packets claiming to be from the internal network when they arrive on the external network connection. Often your Internet provider can implement this type of rule in the router that feeds your site.
The first line of Listing 3 will exec in.fingerd if the requesting host is a member of trusted.external.network. The second line will match all others and cat a message of your choice. This might be a “fake” finger output to mislead attackers or a simple explanation that the service is unavailable. Netacl is often used for permissions on services that you are not proxying but can also be used to switch among the proxy or the real service based on the origin of the connection. This feature will be discussed in more detail later.
The netperm-table also contains configuration information for all of the proxies, as shown in Listing 4. The format is similar to the netacl format, and each rule can contain multiple lines. These options will be discussed in more detail for each proxy later.
|Happy Birthday Linux||Aug 25, 2016|
|ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs||Aug 24, 2016|
|Updates from LinuxCon and ContainerCon, Toronto, August 2016||Aug 23, 2016|
|NVMe over Fabrics Support Coming to the Linux 4.8 Kernel||Aug 22, 2016|
|What I Wish I’d Known When I Was an Embedded Linux Newbie||Aug 18, 2016|
|Pandas||Aug 17, 2016|
- Happy Birthday Linux
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs
- What I Wish I’d Known When I Was an Embedded Linux Newbie
- Updates from LinuxCon and ContainerCon, Toronto, August 2016
- New Version of GParted
- NVMe over Fabrics Support Coming to the Linux 4.8 Kernel
- All about printf
- Tor 0.2.8.6 Is Released
- Blender for Visual Effects
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