Home / Documents / Tutorials / Sunscreen
 
 
 
 
 
 
 
 
 
 
 
 
 DOCUMENTS 
 TUTORIALS 

Installing SunScreen

Vu Pham

Last revised: Feb 11, 2003

This note is my practice on installing SunScreen 3.2 for Solaris 9. I hope this note will be able to provide some help to Sunscreen beginners like me. This note is pretty simple, and I would appreciate any criticism so that this note can be more helpful.

Introduction

I have had not so much luck with both the GUI installation and the GUI administration, therefore only the command line interface is presented here. Also this note is based on a Sunscreen working in ROUTING mode only. This note is just a quick start only so that the beginners can get the concepts. For more information on SunScreen, you can check the following sites:

I set up this firewall on a box that has three NICs as follows: ifconfig -a

  dnet0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 1
            inet 192.168.253.20 netmask ffffff00 broadcast 192.168.253.255

  elxl0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
            inet 65.112.226.103 netmask ffffffe0 broadcast 65.112.226.127

  rtls0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
            inet 192.168.230.20 netmask ffffff00 broadcast 192.168.230.255

  lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 4
            inet 127.0.0.1 netmask ff000000 

dnet0 and rtsl0 connect to my two internal networks 192.168.253.0/24 and 192.168.230.0/24, and elxl0 is the gateway to the Internet. I would like to be able to set up the firewall so that:

  • PC on network 192.168.253.0/24 can access to the firewall (through SSH) as well as the Internet through dynamic NAT mode.
  • PC on network 192.168.230.0/24 can not access to the firewall but can access to the Internet through dynamic NAT mode.

Of course, all the networking connections, default router, netmasks, dns settings are set already.

Install SunScreen 3.2

SunScreen 3.2 can be installed from the CD 2 of 2 in the directory /Solaris_9/ExtraValue/CoBundled/SunScreen_3.2.

cd /cdrom/sol_9_1202_ia_2/Solaris_9/ExtraValue/CoBundled/SunScreen_3.2
./install -nodisplay

The script will ask you for some things, select the local access mode, routing mode and restrictive policy.

Right after installation, your system may have one rule or none, depending on what option you chose Restrictive or Permissive, when installing Sunscreen. I prefer starting from no rule at all, therefore I choose "restrictive" policy.

Because I want the firewall to allow packet forwarding, IP forwarding needs to be turned on. A good way to do this is adding an init script that issues the command:

ndd -set /dev/ip ip_forwarding 1

Policy and SunScreen objects

When the firewall has no rule at all, it means everything is disallowed. You must access to this box from the console to edit SunScreen objects. Under SunScreen a set of firewall rules called policy. Each policy may have multiple versions. After each change and save of a policy, a new version of the policy is saved. Right after installing, SunScreen creates a policy Initial and its first version Initial.1.

The main command line program for SunScreen is ssadm. The quick syntax of using this command is ssadm sub-command parameters.

To copy with policy, the sub-command for ssadm is policy and its common parameters are -c for copying, -l for listing, -d for delete. I prefer copying that policy to my own policy to practice. For some reason, I chose the name FatDog for practice.

ssadm policy -c Initial FatDog

To add rule to this new policy, we use the command edit (don't forget to su to root first)

ssadm edit FatDog

  Loaded common objects from Registry version 24
  Loaded policy from FatDog version 1
  edit> _ 

The command prompt edit> will appear and wait for your sub-command. To view the rule list of the edited policy, we use sub-command list rule (actually, sub-command list with parameter rule) at the edit prompt. Because this is a new restrictive policy (that is copied from the original restrictive policy Initial), there is no rule. It means no access, and no log. The first rule I make is "no access, with log" so that I can debug while I am practicing with rule/objects. The common syntax for "add rule" is:

add rule service from-address to-address access-type parameters

  edit> list rule
  edit> add rule * * * DENY LOG DETAIL ICMP NET_UNREACHABLE
  edit> list rule
  1 "*" "*" "*" DENY LOG DETAIL ICMP NET_UNREACHABLE
  edit>

Note:  All the SunScreen parameters (DENY, LOG, DETAIL ...) are case-sensitive.

For each incoming packet, SunScreen will check it with the rule list and the state table. If the packet matches any rule, the checking process will stop. If the packet matches any entry in the state table, the checking process will stop. Entries in the state table are created when there are connections initiated before.

The first list rule shows no rule. Then we add a rule that say "for all services, from anywhere to anywhere, deny them and log with full detail. Also reply to icmp query with net_unreachable error". The 2nd list rule will show this rule as rule number. We need to save this update, exit the editor, and activate the this new policy.

  edit> save
  Saved policy to FatDog version 2
  edit> quit

ssadm activate FatDog

  Configuration activated successfully on wireless.

ssadm active

  Active configuration: wireless default FatDog.2
  Activated by vu on Tue Feb 04 09:58:38 2003

We save and you can see that SunScreen saves this new policy to FatDog version 2. When we activate the policy FatDog, the latest version, FatDog.2 in this case, is loaded and active. Now we can check the log: ssadm log get | ssadm logdump -i -

  1 elxl0 (256: deny rule or no pass rule) 0.00000 coh-rim.sivell.com ->
            external_intf TELNET C port=40635 
  2 dnet0 (256: deny rule or no pass rule) 21.84942 192.168.253.11 -> 
           192.168.253.255 UDP D=137 S=137 LEN=58
  3 elxl0 (256: deny rule or no pass rule) 40.83994 coh-rim.sivell.com -> 
            external_intf FTP C port=40641 
  4 dnet0 (256: deny rule or no pass rule) 66.05102 wireless.sivell.com -> 
            192.168.253.201 DNS C port=32844 
  5 dnet0 (256: deny rule or no pass rule) 71.05989 wireless.sivell.com -> 
            192.168.253.201 DNS C port=32844 
  6 dnet0 (256: deny rule or no pass rule) 80.93324 192.168.253.100 -> 
            192.168.253.255 UDP D=138 S=138 LEN=209

Note:  At this time, you can see there is pause of this command. We will explain and solve this later below.

The sub-command log get (again, sub-command log with parameter get) will send the binary data to the standard output, therefore we pipe it to ssadm with sub-command logdump and parameter -i - (you can see that this logdump parameter is very similar to the snoop command). In this policy, the log will get long pretty quick because it log everything, you may need to clear it with.

ssadm log clear

Policy Editor

SunScreen uses "objects" to refer to each type of objects that the firewall rules refer to . We use the policy editor to view/add/delete these objects. At this time, we pay attention on address and service objects only.

Address objects

To view address objects, use list address or list address address_name

ssadm edit FatDog

  Loaded common objects from Registry version 24
  Loaded policy from FatDog version 2
  edit> list address 
  "dnet0.net" RANGE 192.168.2 53.0 - 192.168.253.255
  "elxl0.net" RANGE 65.112.226.96 - 65.112.226.127
  "rtls0.net" RANGE 192.168.230.0 - 192.168.230.255
  "wireless_dnet0" GROUP { } {}
  "wireless_elxl0" GROUP { } { }
  "wireless_rtls0" GROUP { } { }
  edit> list address *
  "*" RANGE 0.0.0.0 - 255.255.255.255
  edit> list address localhost
  "localhost" GROUP { } { }
  edit>

After installing, SunScreen will create some address objects based on the NIC interfaces of the system, besides the special objects * and localhost . . localhost is ADDRESS object that has the IP address of all notwork cards that SunScreen controls. My system has three interfaces, dnet0, elxl0 and rtls0, and SunScreen creates three corresponding address object of type RANGE and GROUP. We can explain them as follows: dnet0.net is an ADDRESS object of type RANGE with values from 192.168.253.0 to 192.168.253.255, rtls0.net is an ADDRESS object of type RANGE with values from 192.168.230.0 to 192.168.230.255.

The syntax for adding ADDRESS objects is:

add address address_name TYPE parameters

TYPE can be HOST, RANGE or GROUP. Again, these parameters are case-sensitive.

The followings are examples for adding ADDRESS objects.

  edit> add address internal_230 RANGE 192.168.230.1 192.168.230.254 
        COMMENT "192.168.230.0/24 w/o broadcast and network address"
  edit> add address internal_253 RANGE 192.168.253.1 192.168.253.254 
        COMMENT "192.168.253.0/24 w/o broadcast and network address"
  edit> add address linux_gamma HOST 192.168.230.10 COMMENT "
        RH8 for test on network 192.168.230.0/24"
  edit> add address all_internal GROUP {internal_230 internal_253} {localhost}

The first three commands are pretty understandable. The fourth command creates a GROUP address that may include some ADDRESS objects (in the first {}) and may exclude some ADDRESS objects (in the second {}). In this case, the address object all_internal includes all IP addresses in the ranges specified by internal_230 and internal_253, and not include the IP addresses of the firewall. all_internal are all host addresses behind the firewall.

To delete address object, we use "delete address object_name", but note that if you misspelled the object name, the policy editor will not complain at all. Therefore, after deleting objects, re-list the object to be sure it does not exist. [What if you misspelled the object name in both the command delete and list?]

Service objects

SunScreen has a lot of predefined service objects. To view service objects, use list service or list service service_name

  edit> list service common "common" GROUP "tcp all" "udp all" "syslog"
     "dns" "rpc all" "nfs prog" "icmp all" "rip" "ftp" "rsh" "real audio"
     "pmap udp all" "pmap tcp all" "rpc tcp all" "nis" "archie" 
     "traceroute" "ping"

You can see that the predefined object common covers pretty much common services that we use. We need a service object ssh in order to allow hosts on network 192.168.253.0/24 to access to the firewall as stating above. SunScreen already creates the service ssh, but for the purpose of practice, we add another ssh service, called myssh.

  edit> add service myssh SINGLE FORWARD tcp PORT 22

Allow network 192.168.253.0/24 to access the firewall

Now we already have necessary objects, we can add this rule.

  edit> add rule myssh internal_253 localhost ALLOW COMMENT 
        ".253 network access firewall via SSH"
  edit> list rule  
  1 "*" "*" "*" DENY LOG DETAIL ICMP NET_UNREACHABLE
  2 "myssh" "internal_253" "localhost" ALLOW COMMENT 
        ".253 network access firewall via SSH"

Remember that the rule checking process will stop after first match rule. In the above listing, all access will match the first rule "no access at all" therefore the 2nd rule will never be used. We need to move the 2nd rule to be before the 1st rule. We can do it with the command move rule.

  edit> move rule 2 1
  edit> list rule 
  1 "myssh" "internal_253" "localhost" ALLOW COMMENT 
        ".253 network access firewall via SSH"
  2 "*" "*" "*" DENY LOG DETAIL ICMP NET_UNREACHABLE

Now we can save the policy and activate it.

  edit> save
  Saved policy to FatDog version 3
  edit> quit

ssadm activate FatDog

  Configuration activated successfully on wireless.

ssadm active

  Active configuration: wireless default FatDog.3
  Activated by vu on Tue Feb 04 13:15:44 2003

I use on a host in .253 network, I am able to ssh into the firewall, but there is a pause at the ssh login. In fact, from the example of getting log above, we already have a pause on that process. The reason is our current rule gives no DNS access, therefore the firewall can not make the reversed name resolution. We need to allow DNS access from this firewall. We need to add a rule that allow the firewall to access to a dns server. In my case, it is a local cache dns server at the address 192.168.253.201.

ssadm edit FatDog

  Loaded common objects from Registry version 26
  Loaded policy from FatDog version 4
  edit> add address cache_dns_server HOST 192.168.253.201 COMMENT 
        "local cache dns server"
  edit> add rule dns localhost cache_dns_server ALLOW
  edit> list rule 
  1 "myssh" "internal_253" "localhost" ALLOW COMMENT 
        ".253 network access firewall via SSH"
  2 "*" "*" "*" DENY LOG DETAIL ICMP NET_UNREACHABLE
  3 "dns" "localhost" "cache_dns_server" ALLOW
  edit> move rule 3 1
  edit> save
  Saved policy to FatDog version 5
  edit> quit

ssadm activate FatDog

  Configuration activated successfully on wireless.

After activating this latest policy, I could be able to ssh to the firewall pretty quick, and the ssadm get log shows no pause any more.

Allow all internal hosts to access to the Internet

To do this, we need to steps:

  • to allow all internal IP addresses to be able to get through the firewall to the Internet
  • to allow all internal IP addresses to be able to route through the Internet routers. To do this we use the NAT service.
Allow all internal IP addresses to be able to get through the firewall to the Internet

First of all, we need to define "the Internet". It is all the IP addresses that exclude the internal addresses and the addresses of the firewall itself. We define here an address object, called "The_Internetl", for the Internet. And we will add a rule to allow all internal IP addresses to get through the firewall.

  edit> add address The_Internet GROUP { * } {dnet0.net rtls0.net localhost}
  edit> add rule common all_internal The_Internet ALLOW 
  edit> list rule
  1 "dns" "localhost" "cache_dns_server" ALLOW
  2 "myssh" "internal_253" "localhost" ALLOW COMMENT 
        ".253 network access firewall via SSH"
  3 "*" "*" "*" DENY LOG DETAIL ICMP NET_UNREACHABLE
  4 "common" "all_internal" "The_Internet" ALLOW
  edit> move rule 4 1
Add NAT rule

There are two kinds of NAT: static and dynamic. We will use the dynamic type here. We won't go into details of NAT here, there are a lot of document about NAT everywhere. Here are what I want to have on my network:

  • all internal hosts can access the Internet,
  • the external IP address that will be used for translation is 65.112.226.104, that we will name it Nat_Dyn_Host,
  • the MAC address of my network card is 0:4:75:7a:7d:90
  edit> add address Nat_Dyn_Host HOST 65.112.226.104
  edit> add nat DYNAMIC all_internal The_Internet Nat_Dyn_Host The_Internet

After saving this policy, add an ARP entry for the Nat_Dyn_Host.

arp -s

  65.112.226.104 0:4:75:7a:7d:90 pub

A good place to add this command to is the init script that starts the ndd command to allow IP forwarding.

Now, activate the latest policy, and the internal hosts can access the Internet.

Add a NIC card

I think it is very common to be the case of adding NIC to a firewall. My firewall had 3 NICs at first, and now it has 4. In my scenario, I added a SMC card. After doing all the stuff for configuring this card, my system reboots with the error "ss_plumb_interface: error 31 spwr0" and SunScreen does not control this card. This means all accesses to the system from this card is possible. The hosts that connect to this card are able to telnet to the firewall. If you go to the policy editor, you will see only three interfaces.

  edit> list interface 
  SCREEN "wireless" "dnet0" ROUTING "wireless_dnet0" INCOMPLETE 
  SCREEN "wireless" "elxl0" ROUTING "wireless_elxl0" INCOMPLETE 
  SCREEN "wireless" "rtls0" ROUTING "wireless_rtls0" INCOMPLETE

Currently the only way I know to fix this (I think this is not the correct way, but it works for me – for this simple configuration) is to reconfigure the firewall, reactivate the saved policy, and add appropriate interface objects to the object database of SunScreen.

ssadm configure

After this command is run, the common object database is updated, the new policy (it is the policy you choose when running ssadm configure) will be written to the system as a new version of the policy Initial and this policy will be the activated policy after rebooting the system. We need to re-activate our Convit policy. Listing the interfaces again shows

  edit> list interface
  SCREEN "wireless" "dnet0" ROUTING "wireless_dnet0" INCOMPLETE
  SCREEN "wireless" "elxl0" ROUTING "wireless_elxl0" INCOMPLETE 
  SCREEN "wireless" "rtls0" ROUTING "wireless_rtls0" INCOMPLETE
  SCREEN "wireless" "spwr0" ROUTING "wireless_spwr0" INCOMPLETE 

Now the fourth interface is defined, and the hosts on network 192.168.220.0/24 could not be accessed to the firewall as well as the Internet. SunScreen now controls this interface and the FatDog policy has no rule for this new network 192.168.220.0/24. Again, no rule means no access. In order to allow hosts on this network to be able to access to the Internet, we need to define the all_internal to include this network.

An example of allowing DHCP traffic on SunScreen

I I would like to add the DHCP service on the same SunScreen server as a way of demonstrating how to add rules for SunScreen. There are many protocols but the reason I choose DHCP because it requires adding some "non-standard" objects to Sunscreen object databases. From RFC 2131 "DHCP uses UDP as its transport protocol. DHCP messages from a client to a server are sent to the 'DHCP server' port (67), and DHCP messages from a server to a client are sent to the 'DHCP client' port (68). A server with multiple network address (e.g., a multi-homed host) MAY use any of its network addresses in outgoing DHCP messages."

The above quote shows two rules:

  • to allow udp going from dhcp clients to dhcp server, located on the same Sunscreen server, at port 67,
  • to allow udp going from dhcp server, also the Sunscreen server in this case, to the clients, at port 68.

For the sake of simplicity, I confine the test only on one subnet 192.168.253.0: all the dhcp clients stay on this subnet, then the following two services and rules are requires:

  edit> add service to_dhcp_server SINGLE FORWARD udp PORT 67 BROADCAST 67
  edit> add service to_dhcp_client SINGLE FORWARD udp PORT 68 BROADCAST 68
  edit> add rule to_dhcp_server dnet0.net localhost ALLOW COMMENT 
       "from dhcp clients to dhcp server"
  edit> add rule to_dhcp_client localhost dnet0.net ALLOW COMMENT 
       "from dhcp server to dhcp clients"

If the 2nd rule for replying from dhcp server to dhcp clients is necessary? Will Sunscreen applies the state table for dhcp replies? We will check later. Now we need the dhcp works first, then we will get rid of unnecessary rules later.

After moving these rules to the beginning of the list (so that the rule "*" "*" "*" DENY LOG DETAIL ICMP NET_UNREACHABLE will be the last rule), saving and re-activating, but my dhcp clients could not get the IP addresses as expected.

Using

ssadm log get | ssadm logdump -i -

I get the following log entries:

  4 dnet0 (256: deny rule or no pass rule)503.01001 OLD-BROADCAST -> BROADCAST 
             UDP D=67 S=68 LEN=308
  5 dnet0 (256: deny rule or no pass rule)507.00706 OLD-BROADCAST -> BROADCAST 
             UDP D=67 S=68 LEN=308
  6 dnet0 (256: deny rule or no pass rule)514.00788 OLD-BROADCAST -> BROADCAST 
             UDP D=67 S=68 LEN=308

That's the problem. dnet0.net includes only the subnet broadcast, neither the all-1 broadcast (BROADCAST) nor all-zero broadcast (OLD-BROADCAST). Remembering that the DHCPOFFER will also reply with BROADCAST address, I add two more address objects and rules:

  edit> add address broadcast HOST 255.255.255.255
  edit> add address old_broadcast HOST 0.0.0.0
  edit> add rule to_dhcp_server old_broadcast broadcast ALLOW
  edit> add rule to dhcp_client localhost broadcast ALLOW

After moving the new rules upper, my rules are as follows:

1 "common" "all_internal" "The_Internet" ALLOW
2 "myssh" "internal_253" "localhost" ALLOW COMMENT 
      ".253 network access firewall via SSH"
3 "dns" "localhost" "cache_dns_server" ALLOW
4 "to_dhcp_server" "old_broadcast" "broadcast" ALLOW
5 "to_dhcp_client" "localhost" "broadcast" ALLOW
6 "to_dhcp_server" "dnet0.net" "localhost" ALLOW COMMENT 
      "from dhcp clients to dhcp server"
7 "to_dhcp_client" "localhost" "dnet0.net" ALLOW COMMENT 
      "from dhcp server to dhcp clients"
8 "smb_broadcast" "*" "localhost" DENY 
9 "*" "*" "*" DENY LOG DETAIL ICMP NET_UNREACHABLE

After activating, it WORKS!

Back to the above question is if the rule #7 is necessary? I try to remove it (a convenient way is to move it below the last rule) . Then I find the following log entry:

  34 dnet0 (256: deny rule or no pass rule)2631.99645 wireless.sivell.com -> 
              192.168.253.100 UDP D=68 S=67 LEN=312

It means we need to explicitly to have rule allowing packets from dhcp server to client.

In the log, there is other entry:

  33 dnet0 (256: deny rule or no pass rule)2544.28516 wireless.sivell.com -> 
              192.168.253.100 ICMP Echo request

It means icmp needs to be enable because dhcp server uses icmp to detect if an address is already used by a host or not. The necessary rules for these icmp packets will be:

  edit> add rule "icmp echo-request" localhost dnet0.net ALLOW
  edit> add rule "icmp echo-reply" dnet0.net localhost ALLOW

For summary, here is the full listing of my rules for my Sunscreen server:

  1 "common" "all_internal" "The_Internet" ALLOW
  2 "myssh" "internal_253" "localhost" ALLOW COMMENT 
              ".253 network access firewall via SSH"
  3 "dns" "localhost" "cache_dns_server" ALLOW
  4 "to_dhcp_server" "old_broadcast" "broadcast" ALLOW
  5 "to_dhcp_client" "localhost" "broadcast" ALLOW
  6 "to_dhcp_server" "dnet0.net" "localhost" ALLOW COMMENT 
              "from dhcp clients to dhcp server"
  7 "to_dhcp_client" "localhost" "dnet0.net" ALLOW COMMENT 
              "from dhcp server to dhcp clients"
  8 "icmp echo-reply" "dnet0.net" "localhost" ALLOW
  9 "icmp echo-request" "localhost" "dnet0.net" ALLOW
  10 "ms_common" "*" "localhost" DENY
  11 "*" "*" "*" DENY LOG DETAIL ICMP NET_UNREACHABLE
  • Rule 1 for internal hosts to access the Internet.
  • Rule 2 for my PCs on network 192.168.253.0/24 to be able to telnet to the SunScreen server.
  • Rule 3 for dns access.
  • Rule 4-8 for dhcp.
  • Rule 11 for blocking all others.

The reason of having rule 10 is NOT to log the packets relating to packets for port 137-139 and 445, that there are a lot. "ms_common" is defined as follows:

  edit> list service ms_common "ms_common" GROUP "ms_common_tcp" "ms_common_udp"
  edit> list service ms_common_tcp "ms_common_tcp" SINGLE FORWARD "tcp" 
        PORT 137 - 139 PORT 445 BROADCAST 137 - 139 BROADCAST 445
  edit> list service ms_common_udp "ms_common_udp" SINGLE FORWARD "udp" 
        PORT 137 - 139 PORT 445 BROADCAST 137 - 139 BROADCAST 445

I would add more when I have more time :-)

Related man pages:

  • ifconfig,
  • netmasks,
  • ping.

Copyright © 2003 by Vu Pham. All rights reserved.


Thanks to Vu Pham for his contribution and maintenance of the article.
Original text: http://pluto.sivell.com/~vu/solaris/sunscreen_doc.html

Logo
Top
Last modified: 2003-03-15