Solaris and IP Filter: How To Make Them Your NAT Solution
by Kristy Westphal
|Solaris and IP Filter: How to Make Them Your NAT Solution
last updated May 16, 2001
IP Filter - Freeware to Protect Your Perimeter
So, you are one of those 'lucky' system administrators in a shop that just spent the last dime of your limited budget on a new file server, and you don't get any more money until the next calendar year. And you were just hit by a hacker from the outside because you don't have any perimeter protection. To make matters even worse, you have only one or two assigned public IP addresses to access the Internet.
Things are looking rather bleak right now.
Well, fear not. There is a freeware packet-filter program that runs on numerous versions of UNIX, such as Solaris, FreeBSD, Irix, and HP-UX, that can provide both firewall services and network address translation (NAT). It is feature-rich and flexible and, since it is freeware, the price is especially right for everything from a small home or business network to a larger network. It's called IP Filter and is based on software that came out of the University of California at Berkeley.
This article will examine the ways in which IP Filter can be used for Network Address Translation on a Solaris system. For the purposes of this discussion, the author will be using IPFilter on a Solaris 7, x86 platform. Since the scope of this article is limited to IP Filter's NAT capabilities, for more in-depth discussions of the firewall functionality of IP Filter, it is suggested that readers refer to the following articles:
NAT is a firewall functionality that offers systems administrators the best use of their public IP addresses by allowing them to either map a single public IP address to multiple private ones on their network or multiple public addresses to multiple private ones. Ipnatis a tool that comes with IP Filter and gives it NAT functionality.
The ipnat utility has several functions itself, including letting the user:
Having the ipnat utility available helps to enhance the security of the NAT gateway by allowing for dynamic changes to occur without a system reboot or a service restart.
Installing IP Filter as a NAT
Installation of IP Filter is very straightforward! With most freeware programs, users can expect massive amounts of special drivers and libraries to download. This is not the case with the IP Filter: all users need to get started is Solaris' native
For the NAT configuration, users will need to do perform an additional step to ensure that ipforwarding is enabled on their kernel. First, they should check to see if it is enabled by running the following command:
ndd -get /dev/tcp ip_forwarding
If this returns a 0, the following steps should be taken. However, if the initial step returns a 1, this step can be omitted.
To change this value to a 1 permanently, the user should add ipforwarding to the kernel by running the command:
ndd -set /dev/tcp ip_forwarding 1
Running ndd will only change it for the time being. To change it permanently, the /etc/defaultrouter file should be removed (if it currently exists) and replaced by creating the /etc/gateways file (which can remain empty). With this file in place, the /etc/init.d/inetsvc startup script will change the value to a 1 upon each boot-up.
Users can download the latest version of IP Filter from: http://coombs.anu.edu.au/ipfilter/. The user can then untar the file and run "make solaris" in the directory that he or she wishes to place untar in. Once this process is complete, it can be installed like any other package on Solaris by running "make package". This will run through the package install process, which should present a prompt at some point asking the user whether or not he or she wants to install it. The user should respond yes, and then, once it is installed, the system will have binaries in /usr/kernel/drv, /opt/ipf and a newly installed directory at /etc/opt/ipf.
Note that upon install, ipmon is automatically installed in the startup scripts (see /etc/rc2.d/S65ipfboot for more details).
Issues to Watch For
As with any program, there are certain things in IP Filter that users need to be aware of prior to installation. One prominent warning that is issued on the home page for IP Filter is to avoid using
/usr/local/lib/gcc-lib/sparc-sun-solaris2.3/2.6.3/include/sys/user.h:48, from /usr/include/sys/file.h:15, from ../ip_nat.c:15: /usr/include/sys/psw.h:19: #error Kernel include of psw.h
Then just comment out the line in: /usr/local/lib/gcc-lib/sparc-sun-solaris2.3/2.6.3include/sys/user.h which includes psw.h.
This is useful to know prior to its (unexpected) appearance on the screen. Other than these two issues, the install is very straightforward.
Configuring NAT: What goes into the rules
The user must create a file called /etc/opt/ipf/ipnat.rules, in which the NAT rules will reside. There are four types of rules that go into the config file for NAT, they include:
There are also flags that are used to make up the rules. These flags include:
There are also the standard "from", "to" and "any" words to help round out the rules. IP addresses can be used either by name or by number, as long as it is specified in the /etc/hosts file.
Configuring NAT: A Simple Configuration
The first step in configuring NAT is to determine what the user really wants to do with the NAT functionality. Once the appropriate method (either single public IP address to multiple private addresses or multiple public IP addresses to multiple private IP addresses) has been selected, the user can begin configuration. The pre-install step of adding ip_forwarding to the kernel will already have been completed. A simple configuration for single public IP addresses to a single private address might look something like the one presented below .
map nei0 192.168.5.0/32 -> 0/32 proxy port ftp ftp/tcp map nei0 192.168.5.0/32 -> 0/32 portmap tcp/udp 10000:40000 map nei0 192.168.5.0/32 -> 0/32
Some items to note in this single-to-single address configuration include:
So what would the configuration look like for the same set of rules, but for multiple addresses to multiple addresses?
map nei0 192.168.5.0/24 -> 22.214.171.124/24 proxy port ftp ftp/tcp map nei0 192.168.5.0/24 -> 126.96.36.199/24 portmap tcp/udp 10000:40000 map nei0 192.168.5.0/24 -> 188.8.131.52/24
This configuration simply makes multiple rules for different subnets utilize separate public addresses.
Once the ruleset has been satisfactorily configured, the user should save the ipnat.rules file and restart ipmon by running:
/etc/init.d/ipfboot stop /etc/init.d/ipfboot start
The user should then test the ruleset to make sure it works properly. One thing that should be ensured when troubleshooting any problems with this setup is that the default route of the NAT node is pointed to the IP Filter box to correctly obtain an address.
More Complex NAT Configurations
Some of the more advanced features of NAT include the IP address and port forwarding features. This functionality offers users more granularity in the way in which the gateway can be configured. This is also where the redirection function comes into play in many cases.
NAT and Port Forwarding
The following is a hypothetical situation. Say that a system administrator has a server in the DMZ that needs to have telnet open, but he or she knows that leaving telnet open on port 23 is easy for a hacker to exploit. So, the admin sets up a NAT rule to redirect traffic from an unexpected port on one network address to forward all traffic to the telnet port on the server he or she need to access:
rdr nei0 184.108.40.206/32 port 33 -> 220.127.116.11/32 port 23
To protect from other hosts trying to access telnet on the second server, users can configure a /etc/hosts.equiv file to only accept telnet connections from that IP address. The user can send telnet requests to the first host and get where they need to go and still confuse those that enjoy port scanning on the Internet.
In another hypothetical situation, say that DNS lookups for an external web server point to an IP address of 18.104.22.168. But this server lives in a DMZ, and the sysadmin prefers not to have an IIS or Netscape server necessarily running there because those services can be easily compromised. So, instead, the admin runs the web server on a server behind the firewall on port 8100, which is also not a privileged port. To redirect traffic from 22.214.171.124 on port 80 to this new server and port, the admin could add the follow NAT rule to his or her gateway as well as opening up this port for access through the firewall:
rdr nei0 126.96.36.199/32 port 80 -> 192.168.5.12/32 port 8100
Disadvantages of Using IP Filter For NAT
IP Filter is very feature rich, which can be good and bad. It is good because there are so many things that users can do with IP Filter, depending on what their security goal is and how their choose to configure their firewall. The downside is that IP Filter can be configured in such a way that it may not work exactly as users expect. The key to solving this issue is to test everything - not just the new rule that has just been added, but all the rules in conjunction with this new rule as well.
Rule behavior can be unpredictable. When a new rule is thrown in the mix it may turn off something that the user did not intend to turn off. For instance, say that an administrator is trying to redirect traffic for a certain service to another server. If this server is on the same network segment, then the admin has effectively set up a reflector rather than an address redirection rule, which won't work anyway. Consider the following:
rdr nei0 188.8.131.52/24 port 21 -> 184.108.40.206/24 port 21
If the packet tries to go out of the same interface that it comes in on, the system will get confused.
Another situation in which it is easy to misconfigure the NAT gateway is when a user adds a rule that may already exist in some fashion in the active mappings. If the already-active mappings are not flushed out(using ipnat -F), then the rule might be useless. Good use of procedure in this case will alleviate any confusion.
If possible, users should set up a test environment in which to test rulesets prior to implementation. If this is not possible, then the ipnat does have a "-v" option, which turns on verbose so that users can see more information about how the rules are behaving.
IP Filter is not only an excellent perimeter defense mechanism for networks, but also a great way for the security-minded to teach themselves firewalling and NAT concepts. The key to making it work is in the way it is configured. Testing individual rules when changes are made is a necessary part of building any firewall. Monitoring log files is also important to ensuring that the firewall and NAT gateway behave as expected. It may take time to configure these services the right way, but there are numerous resources available (especially the HOWTO doc) to assist in the process. It is always better to take the time to do these things properly the first time. By doing it quickly and assuming that it is right, rather than testing the configuration, users risk leaving holes in these services which may well be found and exploited.
Kristy Westphal is a versatile network administrator, skilled in troubleshooting and process analysis. She is knowledgeable in several flavors of UNIX and NT, as well as various aspects of information security and disaster recovery planning. She is currently employed by KPMG LLP in their Information Risk Management practice as a consultant.
This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.