Using Solaris IP Filters Information Systems and Technology University of Waterloo Synopsis

Audience: Solaris 10 (and later) System Managers This note is a quick "jumpstart" for Solaris System Managers at the University of Waterloo who want to use IP filters (ie. local host-based firewalls) on Solaris 10 (and we hope later versions of Solaris). The intention is to show you how to configure a baseline that should be adequate for most and give some hints on how you can alter that baseline to meet additional requirements you might have. The baseline we develop is suitable for a "client-only" system managed by xhier that offers very few services beyond remote access via ssh. Building exceptions onto that baseline for web servers, database servers, etc. is not terribly difficult and hopefully weve given enough help to point you in the right direction. Limitations: we will not discuss the configuration required for a system acting as a router or as a NAT server. Both are beyond the scope of this document and, in any case, we discourage the use of any Unix systems for those applications. Our focus is on ingress rules (to protect the system from attack) -- we make no effort on egress rules. Beware: Solaris IP Filters on Solaris 10 are radically different from and replace the SunScreen firewall which was available on earlier versions of Solaris. Solaris IP Filters are derived from open source IP Filter software and will be familiar to those who have used "ipfilters" on freeBSD and other systems.
(by) Reg Quinton, Information Systems and Technology 2005/08/19 - 2008/02/21

Using Solaris IP Filters Information Systems and Technology University of Waterloo Issue
The fundamental problem we need to deal with is this -- the Internet is a very nasty place and systems out of the box expose far too many services. Our Attacks & Attackers data shows that our site is always under attack. Our Vulnerability site shows the issues under attack. So how can we protect ourselves from attack? We can harden systems to eliminate services (see for example our paper on Security Review: Solaris Network Hardening) but there will be required services where you should control access. For example, while its always prudent to eliminate a service like "rlogin" in favour of "ssh" access there are other services which will be required. The classic example at our site is the rsh requirement for xhier management. You need to offer the rsh service but you dont need to offer it to the world -- you only need to expose it to your xhier server. Host-based firewalls are a technology where on the machine itself you configure access controls to services offered. This makes it possible to protect your system from remote attacks (as a network firewall would) but also to protect your system from local attacks -- a network firewall cannot protect a system from malicious peers on the same network segment. Weve used the tcpwrapper to limit access to services managed by inetd but that only works for services managed by inetd and then only tcp services (the tcpwrapper does not handle udp services very well and can do nothing for icmp serivces). The tcpwrapper is an application layer firewall with some serious limitations. IPfilters are a host-based firewall technology layered within the kernel of the operating system. With IPfilters you can limit access to any and all network services. The application layers will not get anything unless the IPfilters allows it. That makes IPfilters a powerful tool for protecting systems. Beware: while IPfilters are an important tool for securing systems they cannot protect you from all problems. You can limit access to ssh with IPfilters -- you cant stop users from picking dumb passwords that are easily guessed!
(by) Reg Quinton, Information Systems and Technology 2005/08/19 - 2008/02/21

Using Solaris IP Filters Information Systems and Technology University of Waterloo How to... Step 1
Before going anywhere you need to have the right packages installed and the right services ready. By default Solaris 10 arrives with IPfilters -- but it is not enabled and the provided configuration does no filtering. The package you require on Solaris 10 are SUNWipfr and SUNWipfu:
[1:20pm sun510]# pkginfo | grep "IP Filter" system SUNWipfr system SUNWipfu IP Filter utilities, (Root) IP Filter utilities, (Usr)

If you dont have these packages installed youll need to install them off the Solaris 10 distribution CDs. Assuming you have the packages installed you should have a couple of services available to you:
[1:24pm sun510]# svcs network/pfil STATE STIME FMRI online Jul_25 svc:/network/pfil:default [1:24pm sun510]# svcs network/ipfilter STATE STIME FMRI disabled Jul_25 svc:/network/ipfilter:default

The packages come with configuration files here:

[1:24pm sun510]# ls /etc/ipf/ ipf.conf pfil.ap

The ipf.conf file is the filter rules that will be applied -- the default configuration has no rules. The pfil.ap lists network interfaces where you might want packet filtering.

Tasks to Perform:
The first step in configuring IP filters is to configure the package to do packet filtering on your network interfaces and configure the associated services so theyre enabled and running. Edit /etc/pfil/pfil.ap and uncomment the name of the network interface (on many older systems the "hme" interface was common). Newer SunFire systems use a mix of "qfe" (sunfire V210, 240), "ce" (sunfire 440), "eri" (Sunblades), and other device names. But for this example lets assume a "hme" device:
[11:19am sun510]# cat /etc/ipf/pfil.ap # IP Filter pfil autopush setup # # See autopush(1M) manpage for more information. # # Format of the entries in this file is: # #major minor lastminor modules #le #qe hme -1 -1 -1 0 0 0 pfil pfil pfil

#qfe #eri #ce #bge #be #vge #ge #nf #fa #ci #el #ipdptp #lane #dmfe

-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1

0 0 0 0 0 0 0 0 0 0 0 0 0 0

pfil pfil pfil pfil pfil pfil pfil pfil pfil pfil pfil pfil pfil pfil

Note: to determine your network interface run the command "ifconfig -a". Make sure both required services are enabled and online:
[11:19am [11:19am STATE online [11:19am [11:19am STATE online sun510]# svcadm enable network/pfil sun510]# svcs network/pfil STIME FMRI Aug_22 svc:/network/pfil:default sun510]# svcadm enable network/ipfilter sun510]# svcs network/ipfilter STIME FMRI 11:24:04 svc:/network/ipfilter:default

Now reboot your system

[11:19am sun510] reboot

When the system reboots you will have a running system with a default rule set that filters nothing.
(by) Reg Quinton, Information Systems and Technology 2005/08/19 - 2008/02/21

Using Solaris IP Filters Information Systems and Technology University of Waterloo How to... Step 2
The second step once you have IP filters running is to configure a rule set for packet filtering and put that rule set into production. The vendor provided rule set has nothing in it although you are filtering nothing is blocked:
[11:46am sun510]# more /etc/ipf/ipf.conf # # ipf.conf # # IP Filter rules to be loaded during startup # # See ipf(4) manpage for more information on # IP Filter rules syntax.

A basic configuration, and a very good baseline to start from, is to configure your machine so that it can connect to anything it wants but protect it so that nobody can connect to any services on it. This is what we like to call a "client-only" configuration (compare with the Windows XP Firewall). A short rule set that would do that:
[11:46am sun510]# more /etc/ipf/ipf.conf # Example A: Simple Client-Only configuration # Allow any outbound traffic from this computer (and the response) pass out quick all keep state # Block anything inbound that I did not originate block in all

Edit a new configuration file as above (or download Example A). Since the running system is using the configuration file found at boot time your edits dont have any immediate affect. To get the running system to use the new configuration file run the command:
[11:46am sun510]# ipf -Fa -f /etc/ipf/ipf.conf

If youve made an errors you will get some gripes and it wont load the configuration. Beware: it should be clear that loading the configuration given cannot be done from an "ssh" session over the network. You must do this from the system console (or include rules in the configuration to allow your network connection).

What you should know....

Rules are applied as IP packets are moved from a physical device through the Solaris kernel to an application (thats the in keyword) and as IP packets are moved from an application through the Solaris kernel to the physical device (thats the out keyword). The IP filter can either pass or block the traffic. Assuming that the system is not a router or a NAT server -- anything coming "in" is for the system, anything going "out" is from the system.

The two rules in this quick configuration work this way. 1. Anything outbound should be permitted, dont bother applying any more rules (thats the quick keyword), and keep a state marker so that anything returned on that same connection is allowed. 2. The final rule blocks everything else. That is a good base configuration for a machine that offers no services. If nobody can connect to any services on your system then all services are well protected. The impact on the user experience is minimal. The local X11 environment will work fine, you can browse the web and can connect to any systems and services you want around the net. Note that applications on other systems cannot connect to your X11 display (see the Beware notes and learn about "ssh" tunnelling). In the next section well extend this configuration by adding some optimization tricks and configuring some exceptions for services we might offer.
(by) Reg Quinton, Information Systems and Technology 2005/08/19 - 2008/02/21

Using Solaris IP Filters Information Systems and Technology University of Waterloo How to... Step 3
In this section well extend the base configuration by adding some optimization tricks and configuring some exceptions for services we need to offer. We recommend you add exceptions as you need them. For testing and development it will be important to log events so you can see whats going on. We recommend you replace the final rule with:
# Example B: Simple Client-Only configuration # Allow any outbound traffic from this computer (and the response) pass out quick all keep state # Block and log anything inbound that I did not originate block in log all

Load this minor change (or download Example B) and you can now monitor the filter as its applied in real time:
[3:55pm sun510]# ipf -Fa -f /etc/ipf/ipf.conf [3:56pm sun510]# ipmon -a 31/08/2005 15:56:33.021348 8x hme0 @0:8 b 129.97.109.1,520 -> 129.97.109.255,520 PR udp len 20 532 IN 31/08/2005 15:56:41.909647 hme0 @0:8 b 129.97.109.75,138 -> 129.97.109.255,138 PR udp len 20 229 IN .... etc.

You may see an IP filter configuration where the first rules permit traffic on the loopback interface:
# Allow loopback traffic pass in quick on lo0 all pass out quick on lo0 all

The loopback interface (it has IP number [127.0.0.1]) will only support IP traffic to and from the machine itself. It enables IP traffic independent of any real networks. Any traffic arriving to/from the loopback interface must have originated on the machine itself. My rule where I allow outbound traffic on any interface and keep the state is sufficient. It does not hurt to add this rule and it may well be required it you implement any outbound filters. If you download Example C youll have a version with that addition. You will encounter rules that block packets arriving from non-routeable private networks:
# block from non-routable addresses block in quick from 10.0.0.0/8 block in quick from 172.16.0.0/12 block in quick from 192.168.0.0/16

One shouldnt normally see any packets from these networks. At our site there is some routing of private networks but most systems should never see these and should block them. If your system offers any services then you probably should block these. For a client only configuration (where all traffic is the result of something you initiate) this problably isnt required. Example D includes this addition. Many people access Unix systems using ssh services for system management. To expose that service to the campus (or to the world) try a rule like:
# Allow ssh inbound #pass in quick proto tcp from any to any port = 22 keep state pass in quick proto tcp from 129.97.0.0/16 to any port = 22 keep state

The exposed rule limits the exposure to just our campus -- we limit off campus access to only a few servers. Critical servers expose the service to only those managers who need access. Example E includes this addition. If your system is a web server that you want to expose to the world add rules like this:
# Allow http and https inbound pass in quick proto tcp from any to any port = 80 keep state pass in quick proto tcp from any to any port = 443 keep state

Port 80 is "http" while port 443 is used for "https" (its not good practice to offer web services on other port numbers). Example F includes this addition. If your system is a mail server youll want to expose a collection of services (but not necessarily all of these):
# Allow inbound mail services (smtp, smtps, submission) pass in quick proto tcp from any to any port = 25 keep state pass in quick proto tcp from any to any port = 465 keep state # pass in quick proto tcp from any to any port = 587 keep state

A mail server accepts mail on port 25, port 465 is an SSL encrypted version of the same, and port 587 is another version of the same but this time the SSL is optional.
# Allow inbound mail services (imap and imaps) # pass in quick proto tcp from any to any port = 143 keep state pass in quick proto tcp from any to any port = 993 keep state

"imap" mail services are for clients to read their mail (from applications like Outlook Express). These days most client applications can handle the SSL encrypted version at port 993 -- I recommend you disable the clear text version (or at least limit it to on-campus only).
# Allow inbound mail services (pop3 and pop3s)

#pass in quick proto tcp from any to any port = 110 keep state #pass in quick proto tcp from any to any port = 995 keep state

"Pop3" services are another way for client applications to retrieve their mail from a mail server. I recommend "imap" over "pop3". If you must offer pop3 services I recommend only the encrypted version at port 995/tcp (or limit the clear text to on-campus only). Example G includes these additions. At UW there are lots of systems that rely on xhier for package management. This requires that a trusted system have rsh access to your server. If your system is an xhier client then youll need a rule like this:
# Allow rsh from arch master pass in quick proto tcp from 129.97.128.175 to any port = 514 keep state

The rsh service is a "tcp" service on port "514". This rule allows inbound traffic from a particular system (that should be your "xhier arch master") to access that port. Example H includes this additions -- note that you must edit the configuration accordingly to list the right client. At UW we have a system called "dominic" at [129.97.128.230] that we use to scan the campus network for problems. You might wish to allow dominic probe your system (its not required), if you do add a rule like this:
# Dominic security scanning of me and others pass in quick from 129.97.128.230/32 keep state

Example I includes this addition. If you expose any services we can test them for problems which might arise. If you have services you havent eliminiated (but have blocked with the firewall) you may get advisories about services you should disable (even though nobody can get to them). We rely on backup/recover services based on EMC Legato, you need to expose some services to your backup/recover server. These rules are sufficient to expose the services required to a machine "hoover" at [129.97.128.9]:
# Allow Legato from hoover pass in quick proto tcp from 129.97.128.9 to any port = 7937 keep state # pass in quick proto tcp from 129.97.128.9 to any port = 7938 keep state # pass in quick proto tcp from 129.97.128.9 to any port = 7939 keep state

Example J includes this addition. Note that the configuration assumes a particular Legato server that will contact you for backups. If youre using a different server then you should edit accordingly. Note: I believe only port 7937 is required -- check your system to determine where you offer the service. While Legato is an RPC service the Portmapper at port 111 does not need to be exposed. For doing network diagnostics its often nice to have all systems respond to a "ping". A good rule to do that, but to limit that to on-campus only testing is:
# Allow pings from campus pass in quick proto icmp from 129.97.0.0/16 to any icmp-type 8

The "ping" is implemented as an "ICMP message of a certain type (ICMP messages dont have port numbers. Example K includes this addition -- some colleagues believe this is an essential rule. The "auth" service on port 113/tcp may be queried by several services you use (email services in particular). We recommend that you dont run the server and instead answer quickly that there is no such server. Add a rule like this:
# Block ident with a TCP RST block return-rst in quick proto tcp to port = 113

If you dont answer quickly then some applications may be slow to start (they want to connect to your "auth" service before proceding). Example L includes this addition -- some colleagues believe this is an essential rule. Along the same lines as the "auth" configuration. You may encounter a final rule like this:
# Block remainingg TCP RST block return-rst in quick proto tcp from any to any

This configuration is just a variation on the "auth" rule. The bad thing about this configuration is that attackers who scan for TCP services will be able to quickly determine that your system exists. For more examples of IP Filters see Creating and Editing Solaris IP Filter Configuration Files at the Sun Documentation Site. Their examples are very useful.
(by) Reg Quinton, Information Systems and Technology 2005/08/19 - 2008/02/21

Using Solaris IP Filters Information Systems and Technology University of Waterloo System Logs
You may have noticed a new application running when youve enabled IP filters. There will be a standing daemon called ipmon:
[11:34am root root [11:34am [11:34am ipf.conf [11:35am 21450 sun510]# ps -ef | grep ipmon 21450 1 0 11:24:05 ? 21517 21433 0 11:35:19 pts/3 sun510]# cd /etc/ipf sun510]# ls ipmon.pid pfil.ap sun510]# more ipmon.pid 0:00 ipmon -Ds 0:00 grep ipmon

This daemon will be restarted at boot time. It logs information received from the IP filtering service to the syslog daemon. Some things you need to know: Events are logged to the local0 facilty. You need to configure /etc/syslog.conf to capture and log events. On a busy system there will be a lot of events. Packets that are passed are logged at the "notice" level, those that are blocked are logged at the "warning" level. But nothing is logged at all unless you use the log keyword in your filter rules. See for example, Example B (and others) where we log all packets blocked by our final rule -- very useful when you are trying to debug a problem. You can run ipmon in real time to see what is currently happening -- it will show events as theyre happening:
[11:34am sun510]# ipmon -a 19/08/2005 10:56:54.040122 STATE:CLOSE 129.97.128.175,40937 -> 129.97.109.165,23 PR tcp Forward: Pkts in 18 Bytes in 872 Pkts out 0 Bytes out 0 Backward: Pkts i n 0 Bytes in 0 Pkts out 16 Bytes out 1123 19/08/2005 10:58:00.550294 STATE:NEW 129.97.109.165,32875 -> 129.97.128.10,53 PR udp 19/08/2005 10:58:00.553235 STATE:NEW 129.97.109.165,32878 -> 129.97.128.100,53 P R udp 19/08/2005 10:58:02.030894 STATE:NEW 129.97.109.165,32879 -> 129.97.128.10,53 PR udp 19/08/2005 10:58:02.276093 STATE:NEW 129.97.109.165,32916 -> 129.97.15.123,22 PR tcp 19/08/2005 10:58:10.537350 STATE:NEW 129.97.128.175,740 -> 129.97.109.165,514 PR tcp ....etc.

A related task to the system logs is the summary status of the filter:
[5:05pm sun510]# ipfstat bad packets: in 0 input packets: blocked output packets: blocked input packets logged: blocked output packets logged: blocked packets logged: input 0 out 0 9236 passed 2782 nomatch 0 counted 0 short 0 0 passed 2597 nomatch 0 counted 0 short 0 9112 passed 0 0 passed 0 output 0

log failures: input 0 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 4 lost 0 packet state(out): kept 127 lost 65 ICMP replies: 0 TCP RSTs sent: 216 Invalid source(in): 0 Result cache hits(in): 5084 (out): 0 IN Pullups succeeded: 0 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 216 failures: 0 TCP cksum fails(in): 0 (out): 0 IPF Ticks: 31167 Packet log flags set: (0) none

If you want to see which rules are being applied try

[3:34pm sun510]# ipfstat -h -i 0 pass in quick on lo0 all 53 block in quick from 10.0.0.0/8 to any 3 pass in quick proto tcp from 129.97.0.0/16 to any port = ssh keep state 53 pass in quick proto tcp from 129.97.128.175/32 to any port = shell keep state 0 pass in log quick from 129.97.128.9/32 to any keep state 0 pass in quick proto icmp from 129.97.0.0/16 to any icmp-type echo 38 pass in quick from 129.97.128.230/32 to any keep state 1 block return-rst in quick proto tcp from any to any port = 113 256937 block in log quick all

This output tells me that my rules, see Example C, about the loopback interface arent being applied. That makes me think theres no filtering at all on that device. Or perhaps the "pass out quick all keep state" rule is enough -- after all if its coming in on that interface it must gone out on the same loopback interface. The rule about blocking packets from non-routeable networks has been used several times -- thats odd.
(by) Reg Quinton, Information Systems and Technology 2005/08/19 - 2008/02/21

Using Solaris IP Filters Information Systems and Technology University of Waterloo Beware
The sample IP filter works well to protect a system. But there are some consequences you might not be aware of. Some things you may think should work but wont because of the firewall. Any application that erects a service is going to be a problem. Some problems are easy enough to find work arounds. FTP -- the data channel can be a problem. The traditional FTP client interacts with the FTP server using two channels -- a command channel at port 21/tcp on the server and a data channel from port 20/tcp on the server. The client erects a server on an ephemeral port and the server connects to it from port 20/tcp. This is called "active" mode and it will not work with the ruleset we presented -- the client cannot start a server on arbitrary ports. Fortunately the FTP protocol has a "passive" where the data channel is built with the client connecting to the server and that will work quite well from a firewalled client. Most web browsers (including Mozilla which comes with Solaris 10) implement passive mode ftp by default. The ftp command line client has a passive command to set passive mode (you can also start it in passive mode with "ftp -p"). Many users never access ftp sites, or if they do its from a browser, so this should not be a big issue.
RSH -- the error channel is problematic. The RSH client will offer a services at a low numbered port for the error channel and the RSH server will connect to that port. The

firewall rules we developed prevent the client from starting a server on arbitrary low number ports. If your firewalled system needs to use the "rsh" command then you have to allow all RSH servers to have access to all low numbered ports (tcp ports less than 1024). This is a nasty problem for xhier servers who distribute files using the RSH protocol. It makes them very hard to rigorously firewall. We encourage users to abandon the clear text RSH in favor of the cryptographically strong SSH tool set.
X11 -- the X11 server is a problem. For desktop Solaris systems the display device is an X11

server on port 6000/tcp. If youre in the habit of running X11 applications on various systems with their display back on your console this wont work any longer. You can update the firewall configuration to expose the X11 service to other systems, however, the preferred strategy is to use SSH and tunneling. On backroom servers dont usually have an X11 device so its not an issue there. For Solaris workstations with an X11 display device most applications are run from the same system so the firewall isnt an issue. For applications run on other systems the SSH tunnel is an ideal workaround.

NFS -- the Network File System, for both clients and servers, is awfully hard to firewall. There are quite a few RPC services related to NFS and not all are located at fixed port numbers. The command "rpcinfo -p" will tell you where your RPC services are located. I

understand the ports involved are: The RPC portmapper (see "rpcbind(1M)") offers a service at ports 111/tcp and 111/udp. Both client and server need to offer this. This is a "locator" service so used to find services which arent at fixed ports. The server offers "nfsd(1M)" at ports 2049/tcp and 2049/udp. The server needs to offer this to the client. The server offers a "mountd(1M)" service but this will be located at an ephemeral port number -- I understand this will be a number bigger than 32768. Youll need to experiment to find the range that works for you but 32768-33000/tcp and 32768-3300/udp ought to be sufficient. The server might offer a "rquotad(1M)" service (its optional for reporting file quotas to clients) at an ephermal port number in the same range. Both the server and the client need to offer a "statd(1M)" and a "lockd(1M)" service to coordinate file locking between clients and the server. Again these are ephemeral port numbers in the same range, It should be clear that firewalling an NFS environment will be difficult. Difficult, not impossible. At our site I do not recommend using Solaris (or any other Unix) systems as NFS servers. I certainly do not recommnd NFS services on a system thats allocated to other purposes. NFS servers should be single purpose systems. It should it be clear that machines which offer services can use the sample configuration weve provided but will need to have firewall exceptions for the services they offer.
(by) Reg Quinton, Information Systems and Technology 2005/08/19 - 2008/02/21

Using Solaris IP Filters Information Systems and Technology University of Waterloo Summary
Configuring IP filters on Solaris 10 requires that you first: Edit /etc/ipf/pfil.ap to list your network interface. Use svcadm to enable "network/pfil" and "network/ipfilter" Reboot the system to get everything running. The second step is to configure /etc/ipf/ipf.conf. You should work slowly from a baseline. The Sample IP Configuration provided includes all of the examples discussed here as well as some details on services discussed in our Beware section. Theres also sample fragments for key services weve not discussed. When developing an IP filter take advantage of the System Logs to resolve problems.
(by) Reg Quinton, Information Systems and Technology 2005/08/19 - 2008/02/21

Using Solaris IP Filters Information Systems and Technology University of Waterloo Acknowledgments
Jason Testart of the Computer Science Computing Facility here at the University of Waterloo was kind enough to give a morning of his time to show me how to configure IP Filters on Solaris 10. He had the experience with freeBSD and fortunately that ported quickly to the Solaris environment. I am grateful for his help and patience.
(by) Reg Quinton, Information Systems and Technology 2005/08/19 - 2008/02/21

Using Solaris IP Filters Information Systems and Technology University of Waterloo See Also
Sun has lots of good information at the Sun Documentation. For our initial configuration we relied on our existing expertise with IP filters and these documents: Solaris 10 System Administrator Collection System Administration Guide: IP Services Part IV IP Security Chapter 24 Solaris IP Filter (Overview) Chapter 25 Solaris IP Filter (Tasks) The important part is Chapter 25. No doubt there are lots of other good pages you can find at the Sun documentation site and good pages by others at other sites as well.
(by) Reg Quinton, Information Systems and Technology 2005/08/19 - 2008/02/21