Sun Microsystems SunScreen 3.1 Reference Manual

SunScreen™ 3.1
Reference Manual
For the Solaris Operating Environment
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303
U.S.A. 650-960-1300
Part No.806-4128-10
May 2000, Revision A
Copyright 2000 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303 U.S.A. All rights reserved.
This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation.
No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors,
if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers.
Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in
the U.S. and other countries, exclusively licensed through X/Open Company, Ltd.
Sun, Sun Microsystems, the Sun logo, SunSoft, SunDocs, SunExpress, and Solaris are trademarks, registered trademarks, or service marks of
Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered
trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture
developed by Sun Microsystems, Inc.
The OPEN LOOK and Sun™ Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges
the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun
holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN
LOOK GUIs and otherwise comply with Sun’s written license agreements.
RESTRICTED RIGHTS: Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-14(g)(2)(6/87) and
FAR 52.227-19(6/87), or DFAR 252.227-7015(b)(6/95) and DFAR 227.7202-3(a).
DOCUMENTATION IS PROVIDED “AS IS” AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
Copyright 1999 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, Californie 94303 Etats-Unis. Tous droits réservés.
Ce produit ou document est protégé par un copyright et distribué avec des licences qui en restreignent l’utilisation, la copie, la distribution, et la
décompilation. Aucune partie de ce produit ou document ne peut être reproduite sous aucune forme, par quelque moyen que ce soit, sans
l’autorisation préalable et écrite de Sun et de ses bailleurs de licence, s’il y en a. Le logiciel détenu par des tiers, et qui comprend la technologie
relative aux polices de caractères, est protégé par un copyright et licencié par des fournisseurs de Sun.
Des parties de ce produit pourront être dérivées des systèmes Berkeley BSD licenciés par l’Université de Californie. UNIX est une marque
déposée aux Etats-Unis et dans d’autres pays et licenciée exclusivement par X/Open Company, Ltd.
Sun, Sun Microsystems, le logo Sun, SunSoft, SunDocs, SunExpress, et Solaris sont des marques de fabrique ou des marques déposées, ou
marques de service, de Sun Microsystems, Inc. aux Etats-Unis et dans d’autres pays. Toutes les marques SPARC sont utilisées sous licence et
sont des marques de fabrique ou des marques déposées de SPARC International, Inc. aux Etats-Unis et dans d’autres pays. Les produits portant
les marques SPARC sont basés sur une architecture développée par Sun Microsystems, Inc.
L’interface d’utilisation graphique OPEN LOOK et Sun™ a été développée par Sun Microsystems, Inc. pour ses utilisateurs et licenciés. Sun
reconnaît les efforts de pionniers de Xerox pour la recherche et le développement du concept des interfaces d’utilisation visuelle ou graphique
pour l’industrie de l’informatique. Sun détient une licence non exclusive de Xerox sur l’interface d’utilisation graphique Xerox, cette licence
couvrant également les licenciés de Sun qui mettent en place l’interface d’utilisation graphique OPEN LOOK et qui en outre se conforment aux
licences écrites de Sun.
CETTE PUBLICATION EST FOURNIE "EN L’ETAT" ET AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, N’EST ACCORDEE, Y COMPRIS
DES GARANTIES CONCERNANT LA VALEUR MARCHANDE, L’APTITUDE DE LA PUBLICATION A REPONDRE A UNE UTILISATION
PARTICULIERE, OU LE FAIT QU’ELLE NE SOIT PAS CONTREFAISANTE DE PRODUIT DE TIERS. CE DENI DE GARANTIE NE
S’APPLIQUERAIT PAS, DANS LA MESURE OU IL SERAIT TENU JURIDIQUEMENT NUL ET NON AVENU.
Please
Recycle
Contents
Preface
1.
xxi
SunScreen Overview
What Is SunScreen?
1
1
Software and Hardware Requirements
Required Patches
2
4
Java Plug-In Software
4
Compatibility With Other SunScreen Products
SunScreen Lite
5
Limitations
5
Supported Features
6
Online Help and Documentation
2.
SunScreen Concepts
6
9
Security Considerations
SunScreen
5
9
9
How SunScreen Works
10
Routing and Stealth Modes
Routing Mode
Stealth Mode
11
12
12
iii
Both Routing and Stealth Mode
Administration
12
12
Remote Administration
Local Administration
13
13
Locating the SunScreen Screen
Security Policy
14
15
Configuration
15
Dynamic Packet Filtering
16
Centralized Management Group
16
Network Address Translation (NAT)
16
Tunneling and Virtual Private Networks (VPN)
High Availability (HA)
Encryption
Logging
Proxies
17
18
18
19
Using Proxies
19
Event Logging With Proxies
3.
Packet Screening
Policy Rules
19
21
Dynamic Packet Filtering
21
23
Rule Syntax
24
Example of a Rule Configuration
Policy Versions
26
27
Routing, Stealth, HA, and Administration Interfaces
Routing Interfaces
Stealth Interfaces
28
29
Administration Interfaces
iv
17
SunScreen 3.1 Reference Manual • May 2000
29
28
Mixing Routing and Stealth Interfaces on a Single Screen
HA Interface
Addresses
30
30
Individual IP Addresses
Address Ranges
31
Address Groups
32
30
Designing an Addressing Scheme
Services
32
33
Standard Services
34
Modifying or Creating New Services
Service Groups
Time
34
35
37
Screen
38
Screen Object
38
Define Screen’s Name Properly
Certificate and Certificate Groups
Generate Screen Certificate
Associate MKID
4.
30
Administration
39
39
39
40
41
Administering the Screen
41
Remote Administration
Local Administration
42
42
Centralized Management Groups of Screens
Centralized Administration
43
43
Common Objects Used in Centralized Administration
Creating Common Objects and Policies for Multiple Screens
Address Objects
43
44
44
Contents
v
Interface Objects
Rules
5.
44
44
Administration Graphical User Interface
Connecting to the Administration GUI
Browser Title Bar
45
45
46
Navigation Buttons on the Navigation Browser Bar
Universal Resource Locator (URL)
The Administration GUI
Login Page
47
47
48
Changing the Password
Online Documentation
49
49
SunScreen Information Page
49
Administration GUI Navigation Bar and Buttons
The Name of the Screen
50
The Log Browser Tabs on the Information Page
Status Tab
Logs Tab
50
52
The Information Tab
Statistics Tab
Help System
Policies List Page
58
59
The Action Buttons
62
63
64
Policies List Panel
Types of Policies
65
66
Policies List Page Action Buttons
Policy Rules Page
68
69
Administration GUI Navigation Buttons
vi
SunScreen 3.1 Reference Manual • May 2000
49
70
50
47
The Policy Rules Page Command Buttons
Common Objects Panel
Common Objects
71
72
73
Save Is Not Required With Certain Common Objects
Service
74
Service Group
Address
Host
76
78
78
Certificate
82
Certificate Group
Screen
84
86
Interface
93
Proxy User
Group
95
96
Authorized User
98
Administrative User
Jar Signature
Jar Hash
Time
99
99
100
101
Policy Rules Panel
103
Packet Filtering Tab
104
Administrative Access Tab
NAT Tab
119
VPN Tab
122
Administration GUI Limitations
6.
73
115
125
Encryption, Tunneling, and Virtual Private Networks
Encryption and Decryption
127
127
How SunScreen Uses Encryption
128
Contents
vii
Packet Examination
128
Remote Administration
Tunneling
130
Defining a VPN
132
Adding a VPN Rule
VPN Limitations
7.
129
135
136
Network Address Translation
137
Network Address Translation (NAT)
NAT Rules
139
Static NAT
139
One-to-One Translations
137
140
Address Range to Another Address Range
Dynamic NAT
141
Dynamic NAT Collisions
142
Choosing NAT Addresses
NAT Examples
140
144
145
Example One
145
Example Two
146
Scenario 1: DMZ Uses Registered Addresses
Scenario 2: DMZ Uses NAT Addresses
Routing Interface Examples
Stealth Interface Examples
Applying NAT
8.
148
149
High Availability
151
High Availability (HA)
HA Policy
148
151
151
HA Network Connections and Failovers
viii
SunScreen 3.1 Reference Manual • May 2000
152
147
146
Configuring HA
153
Administering HA
9.
Authentication
154
157
User Authentication
157
User Identification
158
Save Is Not Required With Certain Common Objects
Authorized Users
158
Defining an Authorized User Object
159
Creating an Authorized User Object
161
Authorized User Authentication Processing Logic
Administrative User
Proxy Users
158
163
164
164
Defining a Proxy User Object
166
Creating a Proxy User Object
167
Proxy User Processing Logic
170
Null Authentication
171
Referenced Authorized User Authentication
SPECIAL External Method Authentication
User Access Control Processing Logic
RADIUS User Authentication Details
RADIUS Server Configuration
Typical RADIUS Configuration
176
Other vars for RADIUS Configuration
RADIUS Usage
172
174
175
RADIUS Testing
172
173
RADIUS Node Secret Configuration
Other RADIUS Protocol Notes
171
177
178
179
179
Contents
ix
SecurID User Authentication Processing Details
179
ACE/Client, ACE/Agent, and the SunScreen Stub Client
SecurID ACE/Agent
SecurID Stub Client
SecurID Access Paths
181
182
183
SecurID PIN Establishment
184
Typical SecurID Configuration
Other SecurID Details
SecurID Usage
10.
Proxies
185
188
189
191
SunScreen Proxies
191
How Proxies Work
192
Policy Rule Matching
192
Proxy User Authentication
194
Proxy Limitations
194
Save Is Not Required With Certain Common Objects
FTP Proxy
195
FTP Proxy Operation
195
FTP Proxy and Anonymous FTP
FTP Proxy Use
197
Other FTP Proxy Issues
HTTP Proxy
196
197
198
HTTP -> FTP Proxy: The ftp:// Method
HTTP Proxy Operation
202
Java Virtual Machine (JVM)
HTTP Proxy Limitations
SMTP Proxy
x
204
SunScreen 3.1 Reference Manual • May 2000
203
204
200
194
180
SMTP Proxy Operation
Spam Control
205
Relay Control
207
205
Other Mail Configuration Issues
SMTP Proxy Rules
Telnet Proxy
209
210
210
Telnet Proxy Operation
210
Other Telnet Proxy Issues
Telnet Proxy Use
211
212
Using SKIP Encryption with Proxies
11.
Logging
212
213
Packet Logging
213
Logging Limitations
214
Save Is Not Required With Certain Common Objects
Log File Locations
214
Configuring Traffic Log Size
215
Configuring the Global Default Log Size
215
Configuring the Log Size for a Specific Screen
Configuring Events to be Logged
Network Traffic (Packet)
Extended events
Size of Logged Items
Level of Logging
216
217
217
Network Session Summaries
218
218
219
219
Configuring Log Event Limiters
Log Retrieval and Clearing
Log Statistics
214
220
221
223
Contents
xi
ssadm logstats Subcommand
Log Inspection and Browsing
223
224
Log Filters and the logdump Command
logdump Extensions
225
Logged Network Packet Enhancements
General Event Type Enhancements
Log Record Format
226
227
228
Extended Log Event Enhancements
Log Filtering Macros
Log Macro Name and Body
Listing Log Macros
xii
229
230
Displaying and Creating Log Macros
Log Macro Usage
224
231
232
233
236
A.
Migrating From Previous SunScreen Firewall Products
B.
Command-Line Reference
243
C.
Services and State Engines
289
D.
Error Messages
E.
Glossary
319
337
SunScreen 3.1 Reference Manual • May 2000
239
List of Figures
FIGURE 2-1
Sample Network Map 10
FIGURE 2-2
Remote Administration From an Administration Station to a Screen in Routing Mode 13
FIGURE 2-3
Local Administration of a Screen 14
FIGURE 2-4
SunScreen as Internet Firewall Dividing a Network into Several Pieces
FIGURE 3-1
Rule Processing Order in a Screen 22
FIGURE 3-2
Single Host Address 31
FIGURE 3-3
Examples of IP Address Ranges 31
FIGURE 3-4
SunScreen as Internet Firewall
FIGURE 4-1
Remote Administration From an Administration Station to a Screen in Routing Mode 42
FIGURE 4-2
Local Administration of a Screen in Routing Mode
FIGURE 5-1
SunScreen Login Page
FIGURE 5-2
Administration GUI Navigation Buttons
FIGURE 5-3
SunScreen Information Page—Status Tab 51
FIGURE 5-4
SunScreen Information Page—Logs Tab 53
FIGURE 5-5
Retrieval Setting Tab 54
FIGURE 5-6
Information Tab
FIGURE 5-7
SunScreen Information Page—Statistics Tab
FIGURE 5-8
Action Buttons on the SunScreen Information Page
FIGURE 5-9
Policies List Page
15
33
42
46
49
58
60
63
65
xiii
xiv
FIGURE 5-10
Policy Rules Page Showing the Save As Buttons for the Currently Active Policy 67
FIGURE 5-11
Policy Rules Page
FIGURE 5-12
Policy Rules Page Command Buttons
FIGURE 5-13
Common-Objects Panel
FIGURE 5-14
Service Dialog Box for a New Single Service
FIGURE 5-15
Service Dialog Box for a New Single Service with Expanded Filter Table 75
FIGURE 5-16
Service Dialog Box for Service Group
FIGURE 5-17
Address Dialog Box for New Host 78
FIGURE 5-18
Address Dialog Box for New Range 79
FIGURE 5-19
Address Dialog Box for New Group
FIGURE 5-20
Certificate Dialog Box for Generate Screen Certificate
FIGURE 5-21
Certificate Dialog Box for Associate MKID 83
FIGURE 5-22
Certificate Dialog Box for Certificate Group 85
FIGURE 5-23
Screen Dialog Box
FIGURE 5-24
SNMP Tab of the Screen Dialog Box 88
FIGURE 5-25
Primary/Secondary Tab on the Screen Dialog Box 90
FIGURE 5-26
Screen Dialog Box Showing the Mail Proxy Tab 92
FIGURE 5-27
Interface Definition Dialog Box
FIGURE 5-28
Proxy User Dialog Box for a Single Proxy User 95
FIGURE 5-29
Proxy User Dialog Box for Grouping Proxy Users 97
FIGURE 5-30
User Dialog Box for an Authorized User 98
FIGURE 5-31
Jar Signature Dialog Box
FIGURE 5-32
Jar Hash Dialog Box
FIGURE 5-33
Time Dialog Box 102
FIGURE 5-34
Packet Filtering Tab
FIGURE 5-35
Policy Rule Index Dialog Box for ALLOW action 106
FIGURE 5-36
PROXY_HTTP Dialog Box for ALLOW action
FIGURE 5-37
PROXY_FTP Dialog Box for ALLOW action 108
70
71
72
75
77
81
86
93
100
101
104
SunScreen 3.1 Reference Manual • May 2000
107
82
FIGURE 5-38
PROXY_SMTP Dialog Box for ALLOW action 109
FIGURE 5-39
PROXY_Telnet Dialog Box for ALLOW action 109
FIGURE 5-40
Policy Rule Index Dialog Box for DENY Action 110
FIGURE 5-41
PROXY_FTP Dialog Box for DENY action 111
FIGURE 5-42
PROXY_Telnet Dialog Box for DENY action 112
FIGURE 5-43
Policy Rule Index Dialog Box for ENCRYPT Action 113
FIGURE 5-44
Policy Rule Index Dialog Box for SECURE Action
FIGURE 5-45
Administrative Access Tab
FIGURE 5-46
Local Access Rules Dialog Box 116
FIGURE 5-47
Remote Access Rules Dialog Box 118
FIGURE 5-48
NAT Tab
FIGURE 5-49
NAT Definition Dialog Box 121
FIGURE 5-50
VPN Tab 123
FIGURE 5-51
VPN Definition Dialog Box
FIGURE 6-1
Remote Administration From an Administration Station to a Screen in Routing Mode 129
FIGURE 6-2
Effect of Tunneling on Contents of IP Headers 131
FIGURE 6-3
Geographically Dispersed Network
FIGURE 6-4
A Site of Ten Networks, Each with a Mail Server, Protected by Ten Screens
FIGURE 6-5
Policy Rules Panel Showing the VPN Tab with VPN Entries
FIGURE 6-6
Completed Rule Definition Dialog Box for the VPN Rule 135
FIGURE 6-7
VPN Rule
FIGURE 7-1
Scenario 1: Static and Dynamic NAT 146
FIGURE 7-2
Scenario 2: Static and Dynamic NAT 147
FIGURE 8-1
Network With HA Cluster of Screens
FIGURE 9-1
Summary of the Relationship Between Rules,
Authorized Users, Proxy Users, and External User Databases 165
FIGURE 9-2
ProxyUser Example
166
FIGURE 10-1
Screen With a Proxy
192
114
115
120
124
132
134
135
136
152
List of Figures
xv
xvi
SunScreen 3.1 Reference Manual • May 2000
List of Tables
TABLE 1-1
SunScreen Installation Requirements 2
TABLE 3-1
Sample Rules Table
TABLE 3-2
Classes and Subclass of State Engines
36
TABLE 5-1
Controls on the SunScreen Login Page
48
TABLE 5-2
Administration GUI Navigation Buttons
50
TABLE 5-3
Status Information
TABLE 5-4
Column Headings on the Log Panel of the SunScreen Information Page
TABLE 5-5
Controls on the Retrieval Setting Tab 55
TABLE 5-6
Filter Terms of the Left-Center Editable Combo Box 56
TABLE 5-7
Filter Terms in the Right-Center Editable Combo Box 57
TABLE 5-8
Fields on the Information Tab 58
TABLE 5-9
Controls on the Traffic Statistics Panel of the Statistics Page
TABLE 5-10
Controls on the SKIP Statistics Panel of the Statistics Tab
TABLE 5-11
Action Buttons on the SunScreen Information Page
TABLE 5-12
Action Buttons on the Policies List Page 68
TABLE 5-13
Policy Rules Page Command Buttons
TABLE 5-14
Common Object Information, Controls, and Buttons
TABLE 5-15
Controls for Service Dialog Box for Single Service
TABLE 5-16
Controls for Service Group Service Dialog Box 77
26
51
53
60
61
63
71
72
76
List of Tables
xvii
TABLE 5-17
78
TABLE 5-18
Controls for New Range Address Dialog Box 80
TABLE 5-19
Controls for the New Group Address Dialog Box 81
TABLE 5-20
Controls for the Certificate Dialog Box for Generate Screen Certificate
TABLE 5-21
Controls for Associate MKID Certificate Dialog Box
TABLE 5-22
xviii
Controls for New Host Address Dialog Box
84
Controls for Certificate Group Dialog Box 85
TABLE 5-23
Controls for the Miscellaneous Tab of the Screen Dialog Box 87
TABLE 5-24
Controls for the SNMP Tab of the Screen Dialog Box
TABLE 5-25
Controls for the Primary/Secondary Tab of the Screen Dialog Box 90
TABLE 5-26
Controls for the Mail Proxy Tab of the Screen Dialog Box
TABLE 5-27
Controls for the Interface Definition Dialog Box
TABLE 5-28
Controls for the Proxy User Dialog Box for a Single Proxy User
TABLE 5-29
Controls for the Proxy User Dialog Box for Grouping Proxy Users
TABLE 5-30
Controls for the User Dialog Box for
an Authorized User Object and an Administrative User Object 98
TABLE 5-31
Controls for the Jar Signature Dialog Box
TABLE 5-32
Controls for the Jar Hash Dialog Box 101
TABLE 5-33
Controls for the Time Dialog Box 102
TABLE 5-34
Policy Rules Panel Tabs 103
TABLE 5-35
fields on the Packet Filtering Tab
TABLE 5-36
Controls for ALLOW Action
TABLE 5-37
HTTP Proxy Flags 107
TABLE 5-38
FTP Proxy Flags 108
TABLE 5-39
Controls for DENY Action
TABLE 5-40
Controls For ENCRYPT Action
TABLE 5-41
Controls for SECURE Action
TABLE 5-42
Controls for the Local Access Rules Dialog Box
TABLE 5-43
Controls for the Remote Access Rules Dialog Box
TABLE 5-44
Controls for the NAT Dialog Box 121
88
93
100
105
106
110
113
115
SunScreen 3.1 Reference Manual • May 2000
92
116
118
96
97
82
TABLE 5-45
Controls in the VPN Definition Dialog Box 124
TABLE 7-1
Static NAT Rules
TABLE 7-2
A Dynamic NAT Rule 142
TABLE 7-3
Two Dynamic Addresses 144
TABLE 7-4
Example of a One-Address NAT Table Entry
TABLE 11-1
Sizes of Logged Items
TABLE 11-2
log Subcommands
TABLE 11-3
Extended Items for logdump
TABLE 11-4
Filters for Restriction Various events 228
TABLE 11-5
Optional Attributes 229
140
145
219
222
227
List of Tables
xix
xx
SunScreen 3.1 Reference Manual • May 2000
Preface
The SunScreen™ 3.1 software is part of the family of SunScreen products that
provide solutions to security, authentication, and privacy requirements for
companies to connect securely and conduct business privately over an insecure
public internetwork. Earlier SunScreen firewall products include SunScreen EFS,
SunScreen SPF-100, SunScreen SPF-100G and SunScreen SPF-200, their respective
Administration Stations, SunScreen packet screen software, and SunScreen Simple
Key-Management for Internet Protocols (SKIP) encryption software. This SunScreen
product integrates the two SunScreen firewall technologies: SunScreen EFS and
SunScreen SPF-200.
SunScreen 3.1 Reference Manual For the Solaris Operating Environment contains
background and reference information about SunScreen.
Who Should Use This Book
SunScreen 3.1 Reference Manual For the Solaris Operating Environment is intended for
system administrators responsible for the operation, support, and maintenance of
network security. This manual assumes that you are familiar with UNIX ® system
administration, TCP/IP networking concepts, and your network topology.
Before You Read This Book
You need to have the following tasks completed before you install and administer
your SunScreen:
■
Become familiar with the SunScreen guides:
xxi
SunScreen 3.1 Release Notes, For the Solaris Operating Environment (PN 806-412901)
■
SunScreen 3.1 Installation Guide, For the Solaris Operating Environment (PN8064126-10)
■
SunScreen 3.1 Administration Guide, For the Solaris Operating Environment (PN
806-4127-10)
■
SunScreen SKIP User’s Guide, Release 1.5.1, For the Solaris Operating Environment
(PN 806-5379-10)
Ensure that your system is running one of the following operating environments:
Solaris 2.6, Solaris 7, Solaris 8 (without IPv6) or Trusted Solaris 7.
List the network services by location (configuration matrix) allowed and
disallowed per location used to establish rules.
■
■
■
How This Book Is Organized
SunScreen 3.1 Reference Manual, For the Solaris Operating Environment contains the
following chapters and appendices:
xxii
■
Chapter 1, “SunScreen Overview,” provides a brief overview of the SunScreen
product, including operating system and hardware requirements and
compatibility.
■
Chapter 2, “SunScreen Concepts,” discusses Security considerations,
Administration, Security policy, and Proxies
■
Chapter 3, “Packet Screening,” explains dynamic packet filtering, policy versions,
interfaces, administration, security policy, proxies, and rules
■
Chapter 4, “Administration,” describes the types of administration possible
including information on remote administration, local administration, centralized
management groups of Screens, and creating common objects and policies for
multiple Screens
■
Chapter 5, “Administration Graphical User Interface,” explains the graphical user
interface (GUI), including navigation, page descriptions, and field descriptions.
■
Chapter 6, “Encryption, Tunneling, and Virtual Private Networks,” describes
encryption and decryption, how SunScreen uses encryption, and setting up and
using a virtual private network.
■
Chapter 7, “Network Address Translation,” This chapter contains information on
NAT rules, static and dynamic NAT, and examples of NAT.
■
Chapter 8, “High Availability,” describes high availability (HA), developing a
high-availability (HA) policy, how HA works, and configuring HA.
SunScreen 3.1 Reference Manual • May 2000
■
Chapter 9, “Authentication,” discusses user authentication, authorized user,
administrative user, proxy user, details of RADIUS user authentication, and
SecurID Authentication
■
Chapter 10, “Proxies,” describes SunScreen proxies including how proxies work,
proxy user authentication, FTP proxy, HTTP proxy, SMTP proxy, and Telnet proxy.
■
Chapter 11, “Logging,” contains information on packet logging, log file locations,
configuring traffic log size, retrieving and clearing logs, log statistics, inspecting
and browsing logs, enhancement, and log macros.
■
Appendix A, “Migrating From Previous SunScreen Firewall Products,” contains a
table comparing the commands from SunScreen EFS and SunScreen SPF-200 to
the equivalent commands used in SunScreen.
■
Appendix B, “Command Line Reference,” documents the command-line interface.
■
Appendix C, “Services and State Engines,” lists the services and state engines
supported by SunScreen.
■
Appendix D, “Error Messages,” lists the error messages generated by SunScreen.
■
Appendix E, “Glossary,” lists the terms and their definitions used in the
SunScreen documentation.
Related Books and Publications
You may want to refer to the following sources for background information on
network security, cryptography, and SKIP.
■
Schneier, Bruce, Applied Cryptography, John Wiley & Sons, 1996, 2nd edition,
ISBN 0471128457
■
Chapman, D. Brent, and Zwicky, Elizabeth D., Building Internet Firewalls, O’Reilly
& Associates, 1995, ISBN 1565921240
■
Walker, Kathryn M., and Cavanaugh, Linda Croswhite, Computer Security Policies
and SunScreen Firewalls, Sun Microsystems Press, Prentice Hall, 1998, ISBN
0130960150
■
Cheswick, Bill, and Bellovin, Steve, Firewalls and Internet Security, AddisonWesley, 1994, ISBN 201633574
■
Comer, Douglas E., Internetworking with TCP/IP, Volume 1, Prentice Hall, 1995,
ISBN 0132169878
■
Stallings, William, Network and Internetwork Security Principles and Practice,
Institute of Electrical and Electronics, 1994, ISBN 078031108
■
Garfinkel, Simson, and Spafford, Gene, Practical UNIX and Internet Security,
O’Reilly & Associates, 1996, 2nd edition, ISBN 1565921488
Preface
xxiii
■
Stevens, W. Richard, TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley,
1994, ISBN 0201633469
■
Hunt, Craig, TCP/IP Network Administration, Addison Wesley, 1994,
ISBN 020163469
■
Kaufman, Charlie, Perlman, Radia, et al., Network Security: Private Communication
in a Public World, Prentice Hall, 1995, ISBN 078816522.
■
SKIP IP-Level Cryptography [http://skip.incog.com/]
■
Sun Software and Networking Security [http://www.sun.com/security/]
Typographic Conventions
The following table describes the typographic changes used in this book
xxiv
Typeface
Meaning
Examples
AaBbCc123
The names of commands, files,
and directories; on-screen
computer output
Edit your .login file.
Use ls -a to list all files.
% You have mail.
AaBbCc123
What you type, when
contrasted with on-screen
computer output
% su
Password:
AaBbCc123
Book titles, new words or terms,
words to be emphasized
Read Chapter 6 in the User’s Guide.
These are called class options.
You must be superuser to do this.
Command-line variable; replace
with a real name or value
To delete a file, type rm filename.
SunScreen 3.1 Reference Manual • May 2000
Shell Prompts
The following table shows the default system prompt and superuser prompt for the
C shell, Bourne shell, Korn shell, and SunScreen configuration editor.
Shell
Prompt
C shell
machine_name%
C shell superuser
machine_name#
Bourne shell and Korn shell
$
Bourne shell and Korn shell superuser
#
SunScreen configuration editor prompt
edit>
Online Sun Documentation
The docs.sun.comsm web site enables you to obtain access to Sun technical
documentation on the Web. You can browse the docs.sun.com archive or search
for a specific book title or subject at http://docs.sun.com
Ordering Sun Documentation
For a list of printed documents and how to order them, visit the Sun Documentation
Center on fatbrain.com at http://www1.fatbrain.com/documentation/sun/
Getting Support for SunScreen Products
If you purchased this product from Sun Microsystems and require technical support,
contact your Sun sales representative or Sun Authorized Reseller.
Preface
xxv
For information on contacting Sun, go to the URL:
http://www.sun.com/service/contacting/index.html.
For information on Sun’s Support go to the URL:
http://www.sun.com/service/support/index.html.
xxvi
SunScreen 3.1 Reference Manual • May 2000
CHAPTER
1
SunScreen Overview
This chapter discusses the following topics:
■
■
■
■
What is SunScreen?
Software and hardware requirements
Compatibility with other SunScreen products
Online help and documentation
What Is SunScreen?
SunScreen is a versatile firewall used for access control, authentication, and network
data encryption. SunScreen integrates the two earlier SunScreen firewall products
SunScreen EFS and SunScreen SPF-200 as modes of operation.
Each physical interface can operate in one of two modes: routing or stealth.
Virtual interfaces are supported only in routing mode. An interface in routing mode
has its own IP address and behaves like the interfaces of the SunScreen EFS system.
If two or more routing mode interfaces are present, the firewall subdivides a
network.
An interface in stealth mode does not have an IP address, nor does it have a TCP/IP
stack. Multiple stealth interfaces act like a bridge and do not subdivide a network
with respect to routing.
SunScreen consists of a rules-based, dynamic packet-filtering engine for networkaccess control, and an encryption and authentication engine that allows you to create
secure Virtual Private Network (VPN) gateways by integrating public-key
encryption technology. It is the first firewall to address high availability (HA) for
standards-based encryption. Secure administration is provided through an easy-touse administration graphical user interface (GUI) through a Web browser.
1
SunScreen consists of two components: Screen and Administration Station. The Screen
is the firewall responsible for screening packets and for performing the necessary
encryption and decryption. The Administration Station is where you define your
security policy and from where you administer your Screen or Screens. The two
components can be installed on separate machines for remote administration or on a
single machine for local administration.
SunScreen fuses open-standard SKIP (Simple Key-Management for Internet
Protocols) technology for encryption, authentication, access control, and secure
virtual private networks (VPN). SunScreen incorporates SunScreen SKIP 1.5.1 for
Solaris. You must use the Solaris command line to administer SKIP on the Screen
directly.
See the SunScreen SKIP User’s Guide, Release 1.5.1, for further information regarding
SKIP encryption and administration.
You can administer SunScreen remotely from any computer that has a browser
compliant with JDK 1.1.3 and has a supported version SKIP software installed. SKIP
software is available for the Sun Solaris operating environment and the Microsoft
Windows operating environment.
Software and Hardware Requirements
TABLE 1-1 lists the installation requirements for SunScreen.
TABLE 1-1
SunScreen Installation Requirements
Requirement
Description
Operating Environment
1. Solaris 2.6, Solaris 7, Solaris 8 (with IPv4 only) in either 32–bit or 64–bit mode
for SPARC and Intel Editions
2. Trusted Solaris 7 (SPARC system only).
Administration Station
Browsers supported:
• A Java™-enabled Web browser compliant with JDK™, Release 1.1.3 or later.
–Netscape Navigator™ 4.5 (with and without the Java plug-in) on the SPARC
and Intel platforms
–HotJava™ 1.1 running on the SPARC and Solaris Intel Edition platforms
–Netscape Navigator 4.5 (with or without Java plug-in) on the Intel
platform
–Internet Explorer 4.0 (with or without the Java plug-in) on the Intel
platform
–Netscape 4.0.1 or higher, can be used for all administrative functions except
those requiring local file access. (See below for system requirements for
Internet Explorer and Netscape to run Java plug-ins.)
2
SunScreen 3.1 Reference Manual • May 2000
TABLE 1-1
SunScreen Installation Requirements (Continued)
Requirement
Description
Hardware
1. All SPARCStations, UltraSPARC, and Intel Edition systems that Solaris 2.6,
Solaris 7, and Solaris 8 operating environments support
2. All SPARCStations and UltraSPARC systems that Trusted Solaris 7 supports.
Disk Space
Minimum of 1 Gbyte (with at least 300 Mbytes unused). This space is needed for
the Solaris operating environment, SunScreen software, and sufficient space for
storing packet logs.
Memory
• For machines running the Administration Station: a minimum of 32 Mbytes is
required and 64 Mbytes is strongly recommended.
• For machines running just the Screen: a minimum of 32 Mbytes.
Network Interfaces
Supported1
For the Screen:
1. For SPARC and UltraSPARC systems in routing mode:
• 10–Mbps or 100–Mbps Ethernet interfaces (le, qe, hme, be, qfe)
• Gigabit Ethernet interfaces
• Token Ring interfaces
• ATM (155 and 622 Mbps in LAN emulation mode or classic IP mode)
• FDDI, or PCI-based Ethernet cards.
2. For Intel-based systems: 10 Mbps or 100 Mbps Ethernet interfaces (dnet,
elxl). See supported devices listed at
http://soldc.com.sun/support/divers/hcl/index.html/
3. High availability requires that the two machines be connected by means of a
nonswitching hub2.
The Administration Station3:
1. For SPARC systems: 10–Mbps or 100–Mbps Ethernet interfaces (le, qe, hme,
be, qfe), or FDDI4, or PCI-based Ethernet cards.
2. For Solaris Intel Edition systems: 10–Mbps or 100–Mbps Ethernet interfaces
(dnet, elxl).
Media
CD-ROM drive (and a diskette drive, if you are using issued certificates).
1. The Screen can support up to 15 network interfaces of each type at one time.
2. Alteon switches can be configured to work with SunScreen HA clusters.
3. A remote Administration Station can connect directly to a Screen only through an Ethernet local area network (LAN) or a Fiber Distributed Data Interface (FDDI).
4. An Administration Station can connect to the Screen by an Asynchronous Transfer Mode (ATM) or Token Ring LAN, but only after it
is connected directly to the network by way of an Ethernet or FDDI connection first.
SunScreen includes the HotJava 1.1 software and the SunScreen SKIP for Solaris
software. The global encryption strength is now 1024 bit and 4096 bit replaces 2048
bit as the domestic strength.
Note – Because of a limitation in SunScreen SKIP 1.5.1 for Solaris, the RC2
encryption algorithm is not available when running Solaris 7 in 64–bit mode.
Chapter 1
SunScreen Overview
3
Required Patches
If you are running the Solaris 2.6, the SPARC Edition, the patches that are included
on the CD-ROM for SunScreen in the
/cdrom/cdrom0/sparc/Patches/ directory are automatically installed.
If you are running Solaris 2.6, the Intel Edition, the patches that are included on the
CD-ROM for SunScreen in the
cdrom/cdrom0/i386/Patches/directory are automatically installed.
Note – In addition to the patches provided by SunScreen, install all recommended
and security patches available for your operating environment. For reasons of
security, you should always keep your operating environment up to date by
installing any patches as they become available.
Java Plug-In Software
Java plug-in software makes it possible for applets using Java technology on your
intranet Web pages to use Java Runtime Environment (JRE), instead of the browser’s
default runtime. Java plug-in software is available for Microsoft Windows- and Sun
Solaris-based browsers.
Java plug-in software system requirements:
■
■
Windows 95, Windows 98, or Windows NT 4.0
■
Pentium 90 MHz or faster processor
■
10–MBytes free hard disk space (recommended 20 MBytes)
■
24–MBytes system RAM
Solaris 2.5 or above
■
SPARC or Intel microprocessor
■
10–MBytes free hard disk space (recommended 20 MBytes)
■
32–MBytes system RAM (recommended 48 MBytes)
Java Plug-in software is available at no charge at the following URL:
http://java.sun.com/products/plugin/1.1.2/index-1.1.2.html/
See Appendix A, “Using the Command Line,” in the SunScreen Administration Guide
for instructions on how to install the plug-in software.
4
SunScreen 3.1 Reference Manual • May 2000
Compatibility With Other SunScreen
Products
SunScreen can communicate with older SunScreen firewalls either in the clear or as
part of a VPN.
The ss_client command that is used in SunScreen SPF-200, Release 1.0, and
SunScreen EFS, Releases 2.0 and 3.0, is maintained so that you can still manage
Screens running these versions of the software remotely through the command line.
Note – See Appendix A for information regarding command compatibility with
previous releases. For information regarding the current commands for SunScreen,
see Appendix B.
The SunScreen SKIP encryption system built into SunScreen is completely
compatible with other SKIP implementations, such as earlier releases of SunScreen
firewall products, SunScreen SKIP for Solaris, or SunScreen SKIP for the Microsoft
Windows Operating Environment. SunScreen can exchange encrypted information
with other SunScreen firewall products transparently.
To upgrade to SunScreen from earlier SunScreen firewall releases, see the upgrading
instructions in the SunScreen Installation Guide.
SunScreen Lite
SunScreen Lite is a stateful, packet-filtering firewall that has a subset of the features
in SunScreen. It protects individual servers and small work groups.
This manual is a reference for both the SunScreen and the SunScreen applications.
Keep the following differences and similarities in mind when configuring and
administering SunScreen Lite.
Limitations
The SunScreenLite firewall does not support the following feature that are available
in SunScreen. A SunScreen Lite firewall:
■
Does not support stealth-mode operation.
Chapter 1
SunScreen Overview
5
■
Cannot support more than two routing interfaces; the filtering mechanisms ignore
any other interfaces.
■
Does not support and cannot create the ADMIN, HA, or STEALTH interfaces.
■
Cannot support more than ten unregistered IP addresses that can be translated to
registered addresses using network address translation (NAT); it is limited to two
NAT rules.
■
Cannot be a member of a high availability (HA) cluster.
■
Cannot create and cannot be made the primary Screen in a centralized
management group (CMG).
■
Does not support proxies.
■
Does not support and cannot create the time objects.
■
Ignores the time-of-day field. It makes all rules active while that policy is active.
Supported Features
The SunScreen 3.1 Lite firewall:
■
Can administer a Screen from a remote Administration Station.
■
Supports basic packet filtering.
■
Displays all data for supported SunScreen types and data fields.
■
Can be used in virtual private networks (VPNs).
■
Can be used for secondary machines in a centralized management group.
■
Uses SunScreen SKIP (Simple Key-Management for Internet Protocols) for the
Solaris operation environment for encryption. SunScreen SKIP is included as part
of SunScreen 3.1 Lite and is automatically installed.
Online Help and Documentation
Topical help is available for each page of the administration GUI by clicking the
Help button on a page or by clicking the Documentation button on the SunScreen
navigation buttons banner.
The SunScreen CD-ROM includes a documentation directory that contains files in
Hypertext Markup Language (HTML) and Portable Document Format (PDF) format.
Click the Documentation button for the HTML files. They are located in
/opt/SUNWicg/SunScreen/admin/htdocs/html.
6
SunScreen 3.1 Reference Manual • May 2000
The PDF files of the documentation are located in
/opt/SUNWicg/SunScreen/admin/htdocs/pdf.
The man pages for SunScreen are located in /opt/SUNWicg/SunScreen/man.
The man pages for SunScreen SKIP are located in the standard Solaris man page
directory.
Chapter 1
SunScreen Overview
7
8
SunScreen 3.1 Reference Manual • May 2000
CHAPTER
2
SunScreen Concepts
This chapter discusses the following topics:
■
■
■
■
Security considerations
Administration
Security policy
Proxies
Security Considerations
A company’s assets are at risk when it connects to the Internet. It might want to
provide Internet services for customers and other users of the Internet, while
allowing its employees to connect to the Internet for services or access to corporate
information.
SunScreen
SunScreen divides the network into discrete areas, each served by an interface. You
set up filtering rules to control the access to one area from another area, which can
be another network within your company or an area outside your company.
FIGURE 2-1 shows a sample map of a simple network in which a Screen in routing
mode functions as a firewall and router to connect the Engineering network over an
unsecured public network (the Internet) through a Screen in stealth mode to other
secure networks.
9
ftp-www
server
Engineering hosts
Corporate
hosts
Internet
Routing-mode Screen
Stealth-mode Screen
Remote Administration Stations
FIGURE 2-1
Sales hosts
Sample Network Map
The ftp-www server might be the public area of the company, also called the
demilitarized zone (DMZ), and the engineering, sales, and corporate network
segments might be part of the “private” area. SunScreen can then control access
between these areas and the rest of the Internet.
How SunScreen Works
SunScreen is a Solaris software product supporting Solaris 2.6, Solaris 7, Solaris 8
SPARC Platforms and Intel Platforms and Trusted Solaris 7 SPARC Platform.
Note – Upgrade your system to at least Solaris 2.6; SunScreen cannot support
Solaris 2.5.1 because of Unicode internationalization requirements.
The administration GUI software works on any hardware or software system with a
browser that supports JDK 1.1 (up to and including 1.1.3) and, if you want secure
administration, has end-system SKIP installed.
Integration of the two SunScreen firewall products in SunScreen allows you to create
a stealth-mode firewall as a dedicated perimeter defense and extranet firewall, or a
routing-mode firewall as a traditional firewall on the perimeter of a network or a
remote-access server inside the intranet to segregate departments, or deployed on an
existing application or data server throughout an enterprise to control access and
provide encryption.
SunScreen and SunScreen SKIP use graphical user interfaces called:
10
SunScreen 3.1 Reference Manual • May 2000
■
SunScreen installation wizard
■
SunScreen administration GUI
■
SunScreen SKIP skiptool GUI
With the installation wizard you can configure your Screen in routing mode, which
is the default, or in stealth mode. Following installation, use the administration GUI
to administer your Screen locally on the same machine or remotely from an
Administration Station.
Note – For backwards compatibility and for machines without monitor, the
installation for SunScreen retains the ss_install command.
With the administration GUI, you can administer single Screens and HA clusters of
centralize management groups of Screens locally or remotely
Use the skiptool GUI to encrypt administration commands that travel from the
Administration Station over a potentially insecure network to the Screen. See the
SunScreen SKIP 1.5.1 User’s Guide regarding the skiptool GUI.
The network address translation (NAT) feature enables you to have a Screen map
unregistered internal network addresses to a registered network addresses.
The network address translation (NAT) feature enables you to have a Screen map an
internal network address to a different network address. As it passes packets
between an internal host and a public network, the addresses in the packet are
replaced with new addresses transparently, checksums and sequence numbers are
corrected, and the state of the address map is monitored. You specify when the
ordered NAT rules apply to a packet based on source and destination addresses.
The high availability (HA) feature protects data by providing a set of Screens to
provide failover protection. One member of the HA cluster, the active Screen,
services packets travelling between a protected inside network and a insecure
outside network. Other members, the passive Screens, receive the same packets,
perform the same calculations, and mirror the state of the active Screen, but they do
not forward traffic between the inside network and the outside network.
Individual versions of a policy are copied or saved into a new policy. Each version of
a policy is maintained and you can use either all or a portion of a policy at a later
date.
Routing and Stealth Modes
SunScreen includes routing-mode and stealth-mode capabilities.
Chapter 2
SunScreen Concepts
11
Routing Mode
Routing-mode interfaces have IP addresses and perform IP routing. Routing mode
requires that you connect each interface to a different network with its own network
number.
Access to all proxies is through the transmission control protocol (CP) and can only
run on systems configured in routing mode.
Stealth Mode
Stealth mode firewall partitions an existing single network and, consequently, does
not permit you to subnet the network. Stealth-mode interfaces do not have IP
addresses, and bridge the MAC layer.
In stealth mode, you must configure one interface as an administration interface.
This interface is special case of a routing interface that is configured so that it only
passes encrypted administration traffic to the Screen from a remote Administration
Station.
If all of your interfaces are in stealth mode, SunScreen offers optional hardening of
the OS, which removes packages and files from the Solaris operating system that are
not used by SunScreen.
Both Routing and Stealth Mode
If some of your interfaces are in stealth mode and other interfaces are in routing
mode, you should not use the option of hardening of the OS that SunScreen offers.
Administration
SunScreen consists of two components: Administration Station and a Screen. The two
components can be installed on separate machines with Screen on one or more
machines and another machine as a remote Administration Station, or they can be
installed on a single machine for local administration of a Screen. If both
components are installed on a single machine, the Administration Station can
administer not only the local Screen, but other Screens that are remote as well.
12
SunScreen 3.1 Reference Manual • May 2000
The number of Screens and Administration Stations needed at a site depends on its
network topology and security policies. Typically, one Screen is installed at each
network direct public access location that needs to be restricted. One or more
Administration Stations can manage multiple Screens.
You typically choose whether to administer a Screen locally or remotely when you
install the SunScreen software. You can add a remote Administration Station after
the Screen software has been installed.
Remote Administration
Remote administration from an Administration Station to the Screen, installs the
software packages, including the SunScreen SKIP, on separate machines, as shown in
FIGURE 2-2. SunScreen uses SunScreen SKIP to encrypt all communication between
the remote Administration Station and the Screen.
Internal
Network
Screen
Internet
Administration Station
Administration Station
FIGURE 2-2
External
Network
Remote Administration From an Administration Station to a Screen in
Routing Mode
In FIGURE 2-2, a remote Administration Station on the internal network administers
the Screen located between the internal network and the Internet. This Screen is the
router between the internal network and the Internet. A second remote
Administration Station for this Screen is located on the external network. The
Administration Stations must be configured to communicate with the Screen using
encryption.
Local Administration
Local administration is performed on the same host where the Screen software is
installed, as shown in FIGURE 2-3. Because administrative commands do not travel
over a network, local administration does not require encrypted communication.
Chapter 2
SunScreen Concepts
13
Internal
Network
Administration Station
External
Network
Internet
Screen
FIGURE 2-3
Local Administration of a Screen
Locating the SunScreen Screen
A Screen only controls traffic that passes through it and must, therefore, be placed in
the network so the traffic you want to control passes through it. All packets coming
into the network and leaving it must pass through the Screen that you want to
control the network.
FIGURE 2-3 shows a Screen dividing a network. In this case, the Screen is placed at the
single boundary between the Internet and the corporate network; it controls the
traffic between those two networks.
If multiple paths exist between the Internet and the corporate network, then the
Screen will not work optimally, because, depending on the routing, traffic can pass
through the Screen in one direction, but can bypass it in the reverse direction. To
control the traffic on a network properly, both the incoming traffic and the outgoing
traffic must pass through the same Screen.
FIGURE 2-4 shows a network divided into several pieces by the Screen.
14
SunScreen 3.1 Reference Manual • May 2000
Administration Station
DMZ
ftp
DMZ
www
Corp
Internet
Screen
Engineering
Sales
FIGURE 2-4
SunScreen as Internet Firewall Dividing a Network into Several Pieces
Like the example in FIGURE 2-3, two of these networks are the Internet and the
company’s network. In this example, however, the network is further divided into
several demilitarized zones (DMZ) where public services reside. The advantage of
dividing the network into one or more DMZs is that even if the systems on a DMZ
is compromised, the traffic on that system must still pass through the Screen
Security Policy
A security policy is the collection of decisions an organization makes about network
security and its stance regarding what network activities are permitted or denied.
The most important aspect in installing and administering a firewall is a welldefined security policy.
Configuration
A configuration is the union of one policy with the common objects to form a
complete description of the behavior of one or more Screens. A policy is a named set
of policy objects. For example, when the SunScreen software is first installed, there is
one policy, named Initial. Common objects are data objects relevant to all
policies. Object types are either named or ordered. Named common object types
include address, screen, service, interface, certificate, and time objects. Ordered
objects include filtering rules, NAT rules, administration access rules, and VPN
Chapter 2
SunScreen Concepts
15
gateway descriptions. Neither common objects nor rules include objects loaded into
SKIP but they do include the reference from the certificate name in the common
object registry to the internal identity used by SKIP.
Dynamic Packet Filtering
Dynamic packet filtering allows a Screen, which sits between the client and server, to
examine each data packet as it arrives. Based on information in the packet, state
retained from previous events, and a set of security policy rules, the Screen either
passes the data packet, or blocks and drops it.
SunScreen uses a set of ordered rules to filter packets. When you configure
SunScreen, you translate the security policies for your site into a series of policy
rules that specify which services are to be allowed, what to do with packets for
services that are disallowed, and what to do when packets are dropped. You then
place these policy rules in sequence to specify which rules override others.
Centralized Management Group
The centralized management group feature enables you to locate Screens at different
points in the network to be managed with a standard set of objects through an
Administration Station.
Centralized management reduces the overhead in configuring a set of firewalls.
When firewalls in a set are configured differently, traffic does not flow through them
properly. Centralized management avoids this problem because all the firewalls in
the group share the same data.
Network Address Translation (NAT)
The network address translation (NAT) feature makes it possible to have a Screen
translate one set of addresses to another set. NAT is typically used:
16
■
To hide the internal topology of a network – Here the network’s private
(unregistered) addresses are translated to a set of public (registered) addresses.
All traffic appears to come from this set of public address, rather than from the
network’s private addresses.
■
To use the public addresses assigned to a site efficiently – Many sites have a
limited set of registered addresses assigned to them by the Internet service
provider (ISP). With NAT you can use those addresses efficiently to support a
large internal network. In this case, the addresses of the internal network are
translated to the smaller set of registered addresses assigned by the ISP.
SunScreen 3.1 Reference Manual • May 2000
■
To prevent having to renumber host addresses when changing ISPs – NAT
enables you to map your old public addresses to the new set of registered
addresses assigned to you by your new ISP.
■
To use private or unregistered addresses on your internal network – The Internet
Assigned Number Authority (IANA) has reserved the addresses ranges 10.0.0.0
through 10.255.255.255, 172.16.0.0 through 172.31.255.255, and 192.168.0.0 through
192.168.0.255 for use in private networks. NAT enables you to use these
addresses in your internal network, yet still communicate with other networks by
mapping those addresses into the registered addresses assigned to your site.
NAT works by modifying the address fields in the packet as it passes through the
Screen. In addition to the address fields, the checksum and sequence number fields
in the packet are modified. Certain protocols (such as FTP) also require that data
within the packet containing address information be modified.
Tunneling and Virtual Private Networks (VPN)
Organizations typically have offices in more than one location. SunScreen provides a
tunneling mechanism to let the different offices use public networks as a secure
private network without needing dedicated lines and with no changes to user
applications.
When a tunnel, or virtual private network, is set up between two or more locations, all
data packets traveling from one location to the other are encrypted and wrapped
inside other packets before they are sent over the public internetwork. Encrypting
the packets guarantees that their contents will remain private; anyone capturing
packets with the snoop program on network traffic between the two locations will be
unable to read them. When the packets arrive at the remote location, they are
unwrapped, decrypted, and forwarded to their intended destination.
In addition to protecting the privacy of network traffic, tunneling also lets a site
conceal the details of its network topology from intruders or eavesdroppers. Because
the original packets are encrypted, the source and destination addresses in their IP
headers cannot be read. When the encrypted packets are encapsulated inside other
packets, the new IP headers identify the addresses of the Screens that protect the
locations, not the hosts that originated the packets. Consequently, the network
topology behind the Screens is never exposed.
High Availability (HA)
High Availability(HA) enables you to deploy groups of Screens together in situations
in which the connection between a protected inside network and an insecure outside
network is critical. At any time, one member of the HA cluster is the active Screen,
Chapter 2
SunScreen Concepts
17
which performs packet filtering, network address translation, logging, and
encryption or decryption of packets travelling between the inside and outside
networks. The other members of the HA cluster, the passive Screens, receive the same
packets, perform the same calculations as the active Screen, and mirror the state of
the active Screen, but they do not forward traffic. When an active Screen fails, the
passive Screen that has been running the longest takes over as the active Screen
within 15 seconds. During this time (before the passive Screen takes over), no traffic
will go through the HA cluster.
Encryption
SunScreen uses a combination of public-key and shared-key cryptography to encrypt
and decrypt packets. Any traffic that passes between any two machines or other
SKIP devices can be encrypted, while all traffic between a Screen and an
Administration Station is encrypted.
Logging
SunScreen provides flexible logging of packets. This means that each primary and
secondary Screen keeps a log of its traffic. Logs of the packets are kept on the Screen
that passed or rejected the packets.
In an HA cluster only the active Screen logs network traffic. However, traffic
destined for the active or passive HA machine itself may be logged according to the
rule. This means that some passive Screens may log some traffic. This traffic is only
the traffic to it, not the traffic that is going through it.
You can configure SunScreen to log a packet when it matches a rule or when it does
not match any particular rule. Most frequently, packets matching DENY rules or
packets that are dropped because they do not match any rule are logged. The action
defined in a rule controls whether a packet is logged and what information about the
packet is recorded.
Examining logged packets is useful when you are trying to identify the causes of
problems during configuration or administration. You should also examine logs
periodically for evidence of attempts to break into your network.
Each machine in an HA cluster logs what that system passed or rejected, as well as
any locally processed nonpacket events.
18
SunScreen 3.1 Reference Manual • May 2000
Proxies
A proxy is a user-level application that runs on the Screen. The main purpose of
proxies is to provide content filtering (for example, allow or deny Java applets) and
user authentication.
Using Proxies
SunScreen lets you set up proxies for FTP, HTTP, SMTP, and Telnet protocols.
Although each proxy has different filtering capabilities and requirements, you can
allow or deny sessions based on source or destination addresses of packets. Proxies
share common objects and policy rule files. To start a proxy, you set up rules for a
proxy in your security policy and activate the policy.
Use of these proxies does not require installing any additional client or server
system software. Some changes, however, may be required in system configurations
or user-supplied commands to access protected destinations through the proxies.
Event Logging With Proxies
Event logging (failure and success, including subsystem authentication) through the
log browser supports filtering capabilities to define and store named filtering macros.
The size of the log is configurable. The log collection facility allows the proxies to
add information to the current log. The types of logged events are extensible to
anticipate the evolving use of this facility. Filtering automates uploading, storage,
and post-processing of logs. You can create postprocessing of your choice of
uploaded logs (for instance, analysis and compression).
Chapter 2
SunScreen Concepts
19
20
SunScreen 3.1 Reference Manual • May 2000
CHAPTER
3
Packet Screening
This chapter discusses the following topics:
■
■
■
■
Dynamic packet filtering
Policy versions
Rules
Routing, stealth, HA, and administration interfaces
Dynamic Packet Filtering
Dynamic packet filtering enables a Screen, which sits between the client and server, to
examine each data packet as it arrives. Based on information in the packet, state
retained from previous events, and a set of security policy rules, the Screen either
passes the data packet, or blocks and drops it.
SunScreen uses a set of ordered rules to filter packets. When you configure
SunScreen, you translate the security policies for your site into a series of policy
rules that specify which services are to be allowed, what to do with packets for
services that are disallowed, and what to do when packets are dropped. You then
place these policy rules in sequence to specify which rules override others.
When the Screen receives a packet, it tests the packet against the rules in a policy in
the order in which they are numbered. The Screen does not test each packet against
each rule; it assumes that the first rule to match the service, source address, and
destination address of the packet addresses is the rule that governs the disposition of
the packet. Additionally, if the applicable rule so specifies, the Screen can record a
log message or generate an SNMP alert.
If the packet does not match any rule, the Screen uses its default action for the
interface on which the packet arrived to determine the disposition of the packet.
Typically, this action logs the packet and drops it; other actions such as logging and
emitting an ICMP or SNMP message are available options.
21
The sequence in which a Screen performs packet filtering, network address
translation, and encryption and decryption depends on the direction in which the
packets are moving, as shown in FIGURE 3-1.
SunScreen Functions
Encryption Rules
Filtering Rules
NAT Rules
User
Procs
FIGURE 3-1
TCP/
UDP
IP
Packet
Filters
Source
to
Translated
Source
Encryption
Network
Translated
Destination
to
Destination
Decryption
Rule Processing Order in a Screen
When a host on a private (internal) network sends a packet addressed to an outside
host through a Screen, the Screen does the following:
1. The Screen applies its packet filter rules to the packet to determine whether the
packet meets the criteria of an ALLOW or DENY rule. If the packet meets the
criteria of a DENY rule, then the packet is denied and, if so specified, can make a
log entry identifying the circumstances.
2. If the packet meets the criteria of an ALLOW rule, the Screen determines whether
it should use NAT to convert the source IP address information in the packet. If
NAT is being used, the source address information in the packet is modified.
Depending on the type of packet, the Screen may also modify address
information in the data portion of the packet or modify packet checksums.
3. The Screen determines if the packet should be encrypted based upon the
information in the rule that matched. If the packet should be encrypted, the
Screen calls the SKIP key manager, which identifies the appropriate encryption
keys and algorithms and encrypts the packet. The SKIP key manager passes the
encrypted packet back to the Screen, which then forwards the packet to the public
network.
When a Screen receives a packet addressed to an internal host from a host on the
public network, it performs a similar sequence of actions:
22
SunScreen 3.1 Reference Manual • May 2000
1. If the incoming packet has been encrypted with the Screen’s public key, the Screen
calls the SKIP key manager, which identifies the appropriate keys and decrypts
the packet. The SKIP key manager passes the decrypted packet back to the Screen.
2. The Screen determines whether it should use NAT to convert the packet’s
destination IP address to an internal IP address. If NAT is being used, the address
information in the packet is modified.
3. The Screen applies its filtering rules to the packet to determine whether the
packet meets the criteria of an ALLOW or DENY rule. If the packet meets the
criteria of an ALLOW rule, the Screen forwards the packet to the internal
network. If the packet meets the criteria of a DENY rule, then the packet is
denied.
Policy Rules
You can define rules and order them either from the graphical user interface (GUI)
or the command line.
Policy rules are based on sets of ordered policy rules. You set up these rules to reflect
the security policy for your site. These rules specify the action to be taken for
services between two addresses that are on different interfaces of the Screen. A
collection of rules form a policy.
When you install the SunScreen software, you start with a policy called Initial
that establishes access rules for basic TCP/IP services. You then define policy rules
to allow clear or encrypted communication between hosts that meet your criteria.
Each rule must specify all three selection criteria: source address, destination
address, and type of service. Each rule can also specify what action to take if a
packet meets those criteria. For example, different rules will specify whether the
Screen should forward or drop the packet; encrypt or decrypt the packet; record the
packet in the Screen logs; and issue ICMP messages or SNMP traps concerning the
packet. The default rule is to drop any packet that does not have a specific SECURE,
ENCRYPT. or ALLOW action.
The sequence in which rules are ordered is critical. When the Screen processes
packets, it compares the packet information to each rule in the order it occurs in the
Screen’s active policy. When a packet meets the criteria of a rule, the Screen applies
the actions specified for that rule and disregards the following rules.
Define services for a service group carefully and place the rules in an order that will
permit the services used to pass easily. For example:, If services such as ftp, rsh,
and realaudio are not part of a service group such as tcp_all and a tcp_all
rule occurs first, then the tcp_all rule will pass the ftp packet, which is a tcp
Chapter 3
Packet Screening
23
packet, because it assumes a simple tcp connection. Other special-case processing,
such as a reverse data-port connection from the server back to the client, will not
automatically be allowed by the initial connection as it would had the ftp-based
rule been placed first.
When a packet filter checks to see if a packet matches a rule, the difference between
service or service group, such as ip_all, and a service or service group with
BROADCAST, such as ip_all_with_broadcast, is important. If the service or
service group has the BROADCAST flag set, the destination IP address in the packet
must be a recognized broadcast address. Configure stealth mode to identify the
network and netmask that the Screen partitions properly so that it can correctly
identify what the valid broadcast addresses are. If a packet must pass through the
Screen that has a destination address of one of the broadcast addresses, set
BROADCAST in the service used in the rule to pass the traffic. With respect to all other
destination addresses, ip_all and ip_all_with_broadcast are identical.
Note – When you define rules for specific services (such as telnet, HTTP proxy, ftp,
and the like), you do not automatically pass network control messages that might be
necessary for these rules to work correctly. You may need to add additional rules
that allow this traffic to pass. For example, you can add the icmp all rule that
allows all internet control messages to pass.
You can use the administration GUI or the command line (see Appendix B) to set up
the table of ordered rules for a policy, by means of which you can edit rule
components, such as source and destination addresses, directly. You can change the
order of the rules by dragging and dropping them through the configuration editor.
Rule Syntax
The basic syntax for a rule is:
Service Source_address Destination_address optional_Time optional_Encryption "action"
optional_Proxy
where:
24
■
Service – An individual network service or a group of services provided to users.
Sample services are smtp, rlogin, and ftp.
■
Source_Address – An address object from the client side over which these
services are provided to users. Named addresses to define the network elements
that make up the configuration. A named address can represent an individual
address, a range of addresses, or a group of addresses. Named addresses are also
used to define the network interfaces.
SunScreen 3.1 Reference Manual • May 2000
■
Destination_Address – An address object from the server side over which these
services are provided to users. Named addresses to define the network elements
that make up the configuration. A named address can represent an individual
address, a range of addresses, or a group of addresses. Named addresses are also
used to define the network interfaces.
Note – The version of SKIP that you can use for encryption, is one of two forms:
(1) SKIP_VERSION_1 source_cert dest_cert key_algorithm data_algorithm, or
(2) SKIP_VERSION_2 source_cert dest_cert key_algorithm traffic_algorithm
mac_algorithm.
Encryption is only supported if ALLOW is selected. It is not supported if any proxy
or VPN is selected. Encryption works as follows:
■
If the first certificate is local (the secret key is loaded into SKIP on the Screen),
then the rule is considered an encryption rule. The packet will be encrypted on its
way out of the Screen.
■
If the second certificate is local, then the rule is considered a decryption rule, and
the packet will be verified as having been decrypted accordingly (correct
certificates and algorithms) before it is allowed to pass.
■
If neither certificate or if both certificates are local, then the rule is ignored by the
compilation process.
■
Action – What the Screen should do with packets. The choices are ALLOW and
DENY. The syntax for specifying an action is in the form: ALLOW LOG_options
SNMP_options; for example, ALLOW LOG_SUMMARY SNMP_NONE,or DENY
LOG_options SNMP_options ICMP_options; for example DENY LOG_SUMMARY
SNMP_NONE ICMP_HOST_UNREACHABLE.
Note – Using the underscore with LOG, SNMP, and ICMP options is optional; for
example, LOG_SUMMARY or LOG SUMMARY.
■
Proxy – (Optional) The name of the proxy to be enabled and any flags for the
proxy. Proxy flags are only permitted in a rule when the service is a PROXY_*
service, where * is the type of proxy and the flags must be of the type for that
proxy. The syntax for specifying a proxy is in the form: PROXY_proxy_name
proxy_name flags; for example, PROXY_HTTP HTTP flags, PROXY_FTP FTP flags,
or PROXY_SMTP SMTP flags. The telnet proxy does not take flags.
■
User – (Optional) A name in the proxy database of users. The syntax for
specifying a user is USER user_name, where user_name is a name in the proxy
database.
Note – The optional User field is only supported if the rule is Proxy-ftp or Proxytelnet. Otherwise, the Screen does not support user-based rule criteria.
Chapter 3
Packet Screening
25
■
■
Time – (Optional) A component by means of which you can set up time-of-daybased Policy Rules. The syntax for specifying time is in the form:
time_object_name.
VPN – (Optional) A component by means of which you to no longer specify all
the SKIP information, but have the Screen do it. The syntax for specifying VPN is
in the form: vpn_name.
Note – VPN is not support if any SKIP information is specified, if DENY is selected,
or if any Proxy is specified.
Example of a Rule Configuration
The XYZ Company wants to set up a series of rules to implement the following
security policies:
1. Allow telnet traffic from A (an address object representing an individual host)
to B (an address object representing any host on a specified network).
2. Deny and log mail traffic between A and B.
3. Send NET_UNREACHABLE ICMP rejection messages for rejected telnet traffic.
4. Discard all other packets.
TABLE 3-1 illustrates the rules the XYZ Company would set up to implement this
security policy. Note that the default action would be specified as DENY for each
interface to implement policy 4.
26
TABLE 3-1
Sample Rules Table
Service
From
To
Rule Type
Log
SNMP
ICMP
telnet
A
B
Allow
NONE
NONE
NONE
mail
A
B
Deny
SUMMARY
NONE
NONE
mail
B
A
Deny
SUMMARY
NONE
NONE
telnet
*
*
Deny
NONE
NONE
NET_UNREACHABLE
SunScreen 3.1 Reference Manual • May 2000
Policy Versions
Each version of a policy has an associated version number. Edited policies
automatically generate historical version numbers. Version numbering is
implemented through the administration GUI using the edit subcommand of
ssadm.
When a particular policy is superseded by a new version of that policy, the older
version includes specific information and the actual content of the common object
registry instead of just a reference. An older policy version can become invalid
because of changes that have occurred in the network topology and hardware.
The types of polices are:
■
Policies that use the current set of common objects – These are the regular policies
that share common objects with other regular policies.
■
Policies with a version number – A policy with a version number contains a
snapshot of the current common objects that is embedded in the saved policy and
the name of the policy then contains a dot followed by an incremental number.
The higher the number, the later the version.
■
Currently Active Policy – This policy is extracted from the active policy. The
currently active policy cannot be modified. You can save the common objects in
the registry to a new version.
You can then make the common objects embedded in this version of the policy the
current common objects, overwriting the existing set of common objects.
This approach enables you to save only the rules part of the versioned policy so that:
■
These rules become the current rule for this policy, for example the rules for
policy Intial.10 can be made the rules for the current version of Initial.
■
You can copy the rule to a new name.
Note – The rules created in this way are used with the current set of common
objects. On verifying this policy, you may have to fix any inconsistencies.
Chapter 3
Packet Screening
27
Routing, Stealth, HA, and
Administration Interfaces
Network interfaces on a Screen may be configured as routing, stealth, HA, or
administration interfaces; or you can disable them.
A disabled interface will not filter any traffic. If it is on a Screen in stealth mode, it
passes no traffic. If it is on a Screen in routing mode, the traffic between the disabled
interface is not filtered, but the traffic that leaves the Screen using an “active”
interface (an interface that has not been disabled) will be filtered. All active
interfaces describe what to do with packets that arrive on that interface that do not
match a packet-filtering rule. The fields are LOG, ICMP, and SNMP. If no values are
set in these fields, no action is taken.
The values for LOG are NONE (which is the same as not present), SUMMARY, and
DETAIL.
The values for ICMP are NONE (which is the same as not present),
NET_UNREACHABLE, HOST_UNREACHABLE, PORT_UNREACHABLE,
NET_FORBBIDEN, and HOST_FORBIDDEN.
If SNMP is present, an SNMP packet will be sent; if it is not present no SNMP packet
will be sent.
You can, as an option, associate all interfaces with a specific screen object. In this
case, the value of the interface is only used with the screen object with which it is
associated. If the Screen is part of a centrally managed group of Screens this
association is necessary to distinguish which interface definition belongs to which
Screen.
You can include an optional description of all interfaces in the COMMENT field.
This cannot be longer than 256 characters
Routing Interfaces
Routing interfaces have an IP address and route packets using the standard IP
routing mechanisms in the operating system. Each routing interface is connected to
a different IP network just like a standard IP router. In terms of network placement,
a Screen with routing interfaces replaces a router. A routing interface can receive
remote Administration Station traffic.
28
SunScreen 3.1 Reference Manual • May 2000
Connections to and from proxies can only occur over routing interfaces. Thus, to run
proxies or if you want to install additional network services on the Screen, you must
configure the Screen with routing interfaces.
In summary, use routing interfaces to replace an existing router, to control packet
flow between different IP networks, or if you want to install proxies or other
network services on the Screen.
Stealth Interfaces
Stealth interfaces have no IP address. All stealth interfaces on a Screen are part of the
same IP network. Thus, a Screen with stealth interfaces partitions one IP network
and controls packet flow between those partitions.
Although it operates much like an IP bridge or switch, the Screen with stealth
interfaces does not implement the bridging algorithms that detect loops. Make sure
no loops exist in your network configuration where a packet could be sent out from
one stealth interface and be received on another.
Stealth interfaces also provide a higher degree of security than routing interfaces
because they are separate from the standard IP mechanisms used by the operating
system. Thus, packets flowing through stealth interfaces cannot inadvertently leak
into other network applications running on the system, thereby compromising the
security of the firewall.
A stealth interface can define a set of five routers by IP address, using the ROUTER
#.#.#.# keyword.
In summary, use stealth interfaces when you want to partition an existing IP
network and control packet flow between those partitions without having to modify
the configuration of your existing network.
Administration Interfaces
Because stealth interfaces have no IP address, they cannot provide the IP address
needed for administration traffic. You must, therefore, configure a Screen that has
only stealth interfaces with an additional administration interface. This interface is a
special case of a routing interface configured to only pass administration traffic for
the Screen.
An administration interface is not required for a Screen with routing interfaces.
Chapter 3
Packet Screening
29
Mixing Routing and Stealth Interfaces on a Single
Screen
You can configure a Screen with a mixture of routing and stealth interfaces subject to
the following restrictions:
1. Packets do not flow between the routing and stealth interfaces. You can model a
Screen with a mixture of routing and stealth interfaces as though it were two
completely separate Screens: one configured with the stealth interfaces and the
other configured with routing interfaces. Packets received on a stealth interface
are only sent out to another stealth interface. Packets received on a routing
interface are only send out to another routing interface.
2. Any packet affected by NAT or encryption rules must only pass through the
Screen once.
HA Interface
If the Screen is part of an HA cluster, it must have a single HA interface. You
administer the HA cluster over this interface.
Addresses
Addresses can be an individual address, a range of addresses, or a group of
addresses.
Individual IP Addresses
SunScreen identifies an individual host by linking its unique IP address to an
address object, which can use the name or IP address of the host or some other
identifier. FIGURE 3-2 shows an example of a host identified by its IP address
(172.16.1.1).
30
SunScreen 3.1 Reference Manual • May 2000
172.16.1.1
Internet
FIGURE 3-2
Single Host Address
Address Ranges
An address range is a set of numerically contiguous IP addresses. Networks and
subnetworks are typically identified by an IP address range name. You use the
beginning and ending addresses to identify an IP address range.
You can set up an address object to represent an address range in SunScreen.
FIGURE 3-3 shows examples of ranges of addresses for the Corporate and Sales
networks. For example, the Corporate address object is defined as a range of
addresses from 172.16.3.2 to 172.16.3.255. You could then establish access or
encryption rules for hosts on the Corporate network by indicating the rule applies to
the Corporate address object.
Corporate
172.16.3.2-255
(255.255.255.0)
172.16.3.1
172.16.1.1
Internet
172.16.4.1
Sales
172.16.4.2-255
(255.255.255.0)
FIGURE 3-3
Examples of IP Address Ranges
Chapter 3
Packet Screening
31
Address Groups
An address group is a collection of host addresses, address ranges, and other
address groups. After you set up an address group, you can use it to identify
multiple hosts as a single element. You can define groups in terms of the addresses
they include (“Address group A consists of the IP address 1.2.3.4 and the members
of address group B”), the addresses they exclude (“Address group C consists of all
the hosts on the 192.4.5.0 network except 192.4.5.5 and 192.4.5.9”), or both. Address
groups cannot be self-referential; that is, you cannot include address group X as a
member of address group Y and then define address group Y as a member of
address group X.
Note – There are two addresses you cannot modify: localhost, which is the IP
address or addresses of the actual Screen, and *, which represents all IP addresses.
The value is determined by first, all addresses are included, which means that all the
IP addresses contained in any of them are added to the Address Group. Next, all IP
addresses of all the Addresses that are excluded are removed from the Address
group. You cannot control the order in which the IP addresses are added or
removed, as all includes are done before all excludes.
Designing an Addressing Scheme
You can take several steps when creating address objects to simplify maintenance of
your security policies. When you are planning your addressing scheme, choose
interface names that describe which addresses are on that interface or that reflect the
names of the interfaces. Make naming conventions meaningful and consistent so that
maintenance and daily administration are uneventful.
A network interface is a network connection coming into a Screen through which
one or more IP addresses are accessible. These IP addresses need to be identified to
SunScreen so that IP spoofing can be detected and prevented.
The easiest way to define address objects for network interfaces is to define an
address group for each network interface. You can choose names that identify which
addresses are on that network interface (such as, Corporate, Sales, ftp-www, and
Internet) or names that identify the interfaces by type (such as le0 or qe0).
In most cases, one interface usually has the majority of addresses on it. For example,
the Internet network interface (qe0) in the network illustrated in FIGURE 3-4 has the
most addresses, because it is the interface for all addresses except those in the Corp,
ftp-www, and Sales networks.
32
SunScreen 3.1 Reference Manual • May 2000
ftp-www
(Single Address)
Corp
(Range of
Addresses)
Internet
Sales
(Group of Addresses)
FIGURE 3-4
SunScreen as Internet Firewall
Rather than enumerating all the addresses for the Internet, you can define the
address group for the Internet address object to include all network addresses (“*”)
and then exclude those that you do not want to be part of that address. In the
example shown in the figure, you would define the Internet address object as an
address group that includes all addresses except Corp, Sales, and ftp-www. You
would then define which hosts, networks, or address groups are members of the
Corp, Sales, and ftp-www addresses to exclude them from the Internet address
group.
Services
SunScreen is shipped with a number of predefined network services, such as ftp,
telnet, dns, and rsh. You can modify these services or define new services as
needed, except that you cannot modify the service named * in any way.
Note – A well-defined service must not include two entries for the same port with
different attributes, such as two different filters for the same port but with different
state engines, or the same state engine but with different parameters set.
Chapter 3
Packet Screening
33
Standard Services
Part of setting up your network security policy is to define what network services
will be available to hosts on your internal network and to hosts on the external
network. Generally, most sites need to determine or set up rules that govern the
basic services.
Besides the basic services, every TCP/IP implementation provides services such as
echo, discard, daytime, chargen, and time. For services such as ftp, you can
allow anyone in the internal corporate network to send outbound traffic, but only
allow inbound traffic in this protocol to go to the FTP server. This requires two rules:
one for the outbound traffic and one for the inbound traffic going to the public
server.
Each service uses a state engine, a sort of protocol checker. For example, the FTP state
engine checks port numbers when the ftp service is being used. For more
information on state engines, see Appendix C, “Services and State Engines.”
TABLE C-1 in Appendix C, “Services and State Engines,” lists the single services in
SunScreen, along with the state engine and discriminator (port, RPC program
number, or type). Parameters (state engine modifiers, such as time-outs) and
BROADCAST are indicated where applicable.
Modifying or Creating New Services
You can modify or define existing services or define new services as needed. Each
service must use a predefined state engine. Troubleshooting is easier if you create a
new service rather than modifying an existing one because you do not have to
examine the services to see which one or ones have been modified. You should note
the purpose of the new (or edited) service in the description.
When you define a new service, you must specify a state engine for the new service
to use and identify the various discriminators and parameters appropriate for that
state engine.
Before you can define a new network service, you need to identify how the new
service will work:
34
■
What protocol does the new service use?
■
What ports does the protocol use?
■
If your service is an RPC protocol, what program numbers does it use?
■
If your service is a UDP protocol, how many responses can be sent back for each
request?
SunScreen 3.1 Reference Manual • May 2000
For example, if you have an FTP implementation that uses port 45 for its control port
and port 44 for data, you could define a new FTP service called ftp-45. Refer to
Appendix C, “Services and State Engines,” for more information on state engines,
their discriminators, and their parameters.
You can specify state engines as filters for both the forward and the reverse
direction. The forward filters apply when traffic originates from the From Address
and goes to the To Address in a rule. The reverse filters apply to traffic originating
from a machine in the To Address going to the From Address of a rule.
Normally, rules for stateful services do not have reverse filtering rules. For instance,
an FTP connection always gets established in the forward direction, and the
returning traffic is handled by a state-table entry created when the connection is
initiated. Reverse filtering rules are mostly valuable when you want to allow
nonstateful traffic to return. An example is the nlm rule, which uses the nonstateful
ICMP filter engine. It allows network lock manager (nlm) requests (ICMP type 8)
in the forward direction and nlm replies (ICMP type 0) in the reverse direction.
State engines’ discriminators can optionally be tagged with a BROADCAST attribute.
When BROADCAST is specified for a service, the rules where the service is used allow
communication to broadcast and multicast addresses. If you also want the service to
work for non-broadcast addresses, you must include a filter line both with and
without BROADCAST selected.
Service Groups
You can group network services together to apply a single rule to multiple network
services. This group is called a service group. TABLE C-1 in Appendix C, “Services and
State Engines,” shows the predefined service groups in SunScreen and the services
each includes. Not every service is included in a service group.
You can create additional service groups using any combination of the individual
network services. A useful group to define might be an “internet services” group,
consisting of public services, such as FTP, email, and WWW.
State engines that you use in describing services come in distinct classes and each
class has subclasses. The subclasses form an order for preference. TABLE 3-2 shows the
classes in order of preference—the greater the number, the higher the preference.
Chapter 3
Packet Screening
35
The state engines that are followed by an * can conflict with another state engine
because it is in the same class and has the same subclass ID. An * also follows the
state engine with which it can conflict.
Classes and Subclass of State Engines
TABLE 3-2
Class
36
Subclass
State Engine Name
11
0
nfsro
10
0
nis
9
0
pmap_nis
8
0
pmap_udp
7
0
pmtp_tcp
6
0
rpc_tcp
5
0
rcp_udp
4
1
realaudio*
4
1
rsh*
4
1
sqlnet*
4
1
ftp*
4
0
tcpall
3
2
dns*
3
2
ntp*
3
1
upd_stateless*
3
1
udp_datagram*
3
1
udp*
3
0
udpall
2
1
ping
2
0
icmp
1
3
ipmobile
1
2
iptunnel
1
1
ipfwd
1
0
ip
0
0
ether
SunScreen 3.1 Reference Manual • May 2000
A given service, defined manually to contain multiple state engines or in a service
group that includes multiple services, can only contain a single state engine in a
particular class or subclass for a particular port.
Time
Time objects are specified using a 24-hour clock in 5-minute increments.You use time
objects to set a policy’s time-of-day, day-of-week, and the like in time-based rules. For
instance, you can allow telnet, but only during regular business hours, or after
hours, or outside certain hours.
The policy rule default setting is ANY time, which applies the rule at all times. You
can set a few time-based policy rules that reference the same set of hours, or you can
specify the hours covered for a particular day or range of days, such as Monday to
Friday, 9 AM to 5 PM, local time.
Time is always interpreted as the Screen’s time zone, which requires that you either
have Screen-specific Time definitions to coordinate traffic between the Screens in
different time zones, or have distinctly named time objects and Screen-specific rules.
Note – Although you can define many time objects, only 31 distinct time objects can
be in actual use on any given Screen. You cannot modify the time object named * in
any way; it represents 24 hours a day, 7 day a week—it is the same as if no time
object is used. It is not included in the limit of 31 time objects.
For example, Los Angeles (LA) and New York (NY) have a three-hour difference.
Suppose each site is protected by a Screen. If you only want the two sites to
communicate when they are both within “regular” hours (that is, 8 AM to 5 PM), then
NY is available to communicate to LA between 11 AM and 5 PM, and LA is available
to communicate to NY between 8 AM and 2 PM.
A down-side to this is that during hours that do not overlap, one of the two Screens
allows traffic through while the other does not. So, early in the morning the NY
Screen allows traffic through, but it is blocked by the LA Screen. Similarly, in the
afternoon, the LA Screen is blocked by the NY Screen.
Case 1: Screen-Specific Time Objects
Name
Screen
Value
regular
NY
MONDAY { 11:00 17:00 } TUESDAY { 11:00 17:00 } ...
regular
LA
MONDAY { 08:00 14:00 } TUESDAY { 08:00 14:00 } ...
Chapter 3
Packet Screening
37
Set the rules by typing:
telnet LA NY TIME regular ALLOW
telnet NY LA TIME regular ALLOW
These rules apply to both Screen, although the definition of regular is different for
each Screen
Case 2: Distinctly Named Time Objects
Name
Value
ny-business
MONDAY { 11:00 17:00 } TUESDAY { 11:00 17:00 } ...
la-business
MONDAY { 08:00 14:00 } TUESDAY { 08:00 14:00 } ...
Set the rules by typing:
SCREEN
SCREEN
SCREEN
SCREEN
LA
LA
NY
NY
telnet
telnet
telnet
telnet
LA
NY
LA
NY
NY
LA
NY
LA
TIME
TIME
TIME
TIME
la-business
la-business
la-business
la-business
ALLOW
ALLOW
ALLOW
ALLOW
Screen
In general, editing is better than creating one because they are automatically created
during installation. If you specify a Screen, you can define packet-filtering rules that
encrypt traffic between any two machines, not just between an Administration
Station and a Screen.
Screen Object
The common object Screen defines attributes associated with each distinct Screen.
You can set miscellaneous Screen parameters, SNMP parameters, and mail proxy
parameters for screen objects that already exit.
You create new screen objects to configure high availability (HA) and centralized
management.
38
SunScreen 3.1 Reference Manual • May 2000
Define Screen’s Name Properly
SunScreen automatically chooses a name for each Screen based on the hostname
setting output by uname -n. Various situations exist in which this name is used as
an IP host name (IP address) for remote administration and centralized management
groups.
You must, therefore, define each Screen’s name as a valid IP address for that Screen.
The definition must be accessible through /etc/hosts, NIS, or DNS on every
remote administration station as well as every Screen in a centralized management
group.
You cannot modify the Screen named * in any way.
Certificate and Certificate Groups
Use certificate objects to configure the certificates you use for your SunScreen host
and for remote hosts that communicate securely through your SunScreen.
Note – Changes to the certificate object that pertain to loading into SKIP take effect
immediately without having to be saved. Changes to the certificate object as stored
in the common objects do not take effect immediately and must be saved and only
take effect when the policy in which they are used is activated. For example, in
adding a new certificate, (the certificate is created and loaded immediately into SKIP,
but the name has not been saved as part of the common objects and must be saved.
Renaming a certificate only affects the common objects and must be saved.
The certificate object provides a way to associate a usable name with a SKIP
certificate name space ID/master key ID (NSID/MKID) pair. This naming facility
makes using certificates easier, as well as isolating the Screen configuration from
exact SKIP names.The certificate group allows grouping single certificates that you
want to use together.
Generate Screen Certificate
This task generates a certificate for the Screen.
Chapter 3
Packet Screening
39
Associate MKID
This task is also called the certificate ID and assigns a name to a certificate that
already exists (typically on another machine). You associate a certificate ID when
you want to encrypt communication between two screens or between a screen and
an Administration Station.
40
SunScreen 3.1 Reference Manual • May 2000
CHAPTER
4
Administration
This chapter describes the types of administration possible. It contains information
on:
■
■
■
■
Remote administration
Local administration
Centralized management groups of Screens
Creating common objects and policies for multiple Screens
Administering the Screen
You can administer Screens either through the graphical user interface (GUI) or
through the command line. See Chapter 5 for information on the GUI and
Appendix B for information on the command line.
SunScreen consists of two components: a Screen and an Administration Station. The
two components can be installed on a Screen and a remote Administration Station,
or they can be installed locally on a single machine.
A machine that is being administered remotely can be headless (no monitor) and have
no keyboard. You typically choose whether to administer a Screen locally or
remotely when you install the SunScreen software. You can add a remote
Administration Station after the Screen software has been installed.
The number of Screens and Administration Stations needed at a site depends on its
network topology and security policies. Typically, one Screen is installed at each
network direct public access location that needs to be restricted. One or more
Administration Stations can manage multiple Screens.
41
Remote Administration
Remote administration from an Administration Station to the Screen installs the
software packages, including SunScreen SKIP, on separate machines, as shown in
FIGURE 4-1. Communication between a remote Administration Station and a Screen
must be encrypted.
Screen
Internal
Network
Internet
Administration Station
Administration Station
FIGURE 4-1
External
Network
Remote Administration From an Administration Station to a Screen in
Routing Mode
In FIGURE 4-1, a remote Administration Station on the internal network administers
the Screen located between the internal network and the Internet. This Screen is the
router between the internal network and the Internet. A second remote
Administration Station for this Screen is located on the external network.
Local Administration
Local administration is performed on the same host where the Screen software is
installed, as shown in FIGURE 4-2. Because administrative commands do not travel
over a network, local administration does not require encrypted communication.
Internal
Network
Administration Station
External
Network
Internet
Screen
FIGURE 4-2
42
Local Administration of a Screen in Routing Mode
SunScreen 3.1 Reference Manual • June 2000
Centralized Management Groups of
Screens
Groups of Screens deployed throughout your organization are managed with a set of
configuration objects through an Administration Station. Policies reside on a specific
Screen called the centralized management group’s primary Screen. Many
Administration Stations can manage the Screens.
The centralized management group’s primary Screen, where all configuration objects
reside, manages itself, as well as the centralized management group’s secondary
Screens. The secondary Screens in a centralized management group make some basic
emergency administration possible. For example, if the primary Screen is down for
service, although no central logging mechanism exists for a global view of the logs
on the individual Screens in a centralized management group, you can select a
specific Screen and view its log.
Centralized Administration
Many sites run multiple Screens. With centralized administration, you can keep all
common objects and policies on a central, primary Screen and use it to activate all
the Screens in your site.
The primary Screen is the one that contains the common objects and policies for it
and all the other Screens. The other Screens are the secondary Screens.
Common Objects Used in Centralized
Administration
Centralized administration requires secure communication among the Screens. This
information is contained in the screen object. On the primary Screen, screen objects
must exist for all the Screens. On each secondary SunScreen, Screen objects must
exist for that secondary and the primary Screen.
Note – Once you successfully activate a configuration from the primary Screen, it
will replace objects on the secondary. If these new objects are incorrect, it may be
impossible to activate additional configurations centrally. If so, you can manually
activate an old configuration on the secondary, fix the errors on the primary, and
then activate the configuration again.
Chapter 4
Administration
43
Creating Common Objects and Policies
for Multiple Screens
When creating common objects and policies for multiple Screens, the object or policy
rule by default applies to all Screens controlled by that primary Screen. You can
restrict an object or rule to a single Screen by specifying its name in the Screen field
in objects and rules.
While you could restrict all your objects and rules to a single Screen, the power of
centralized administration comes when you can use common objects and rules to
apply to multiple Screens. The following section provides some pointers on when
this is and is not possible.
Address Objects
Most address objects should be applicable to all the Screens. Sometimes addresses
such as Inside may be different on different Screens. In this case, it is generally
better to make the names unique by adding a suffix or prefix to the name (for
example Inside-East and Inside-West) rather than using the Screen option to
restrict the scope of the object.
Interface Objects
You generally need to limit interface objects to a specific Screen because the names
must be the name of the network interface on that machine. Because you cannot
modify the names, use the Screen entry in the interface object to restrict that object to
a single Screen.
Rules
You set up rules for the entire centralized management group of Screens using the
administration GUI.
44
SunScreen 3.1 Reference Manual • June 2000
CHAPTER
5
Administration Graphical User
Interface
This chapter describes the administration graphical user interface (GUI) for
configuring and administering SunScreen. It contains information on the following
topics:
■
Starting the administration GUI
■
Elements and navigation of the administration GUI
■
Function and controls of each page in the administration GUI
Connecting to the Administration GUI
Connect to the administration GUI by starting a browser that can run Java applets,
such as HotJava, Netscape Navigator, or Microsoft Internet Explorer.
The SunScreen administration GUI uses Java applets to administer and monitor
Screens.
Note – If your network uses proxies (gateways) for Internet access through a
network firewall, you may need to configure your browser to ignore proxies when
you are connecting to a Screen. For example, if you type localhost in the Don’t
Proxy field, your browser will connect to localhost directly. For information on
configuring proxies, refer to the documentation for your browser.
45
Browser Title Bar
FIGURE 5-1 shows the Login page for SunScreen. The title bar of the browser shows
the application to which the browser is connecting.
Browser Title Bar
Browser Navigation Bar
Browser Location Bar
SunScreen Administration
GUI Login Page
Link to Sun’s
Security Home Page
Browser Status Bar
FIGURE 5-1
46
SunScreen Login Page
SunScreen 3.1 Reference Manual • May 2000
Navigation Buttons on the Navigation Browser
Bar
You can use the navigation buttons shown in the navigation bar of the browser to
move from the current page of the administration GUI to a previous page, from the
current page to a next page as available, or to refresh the current page. Each browser
behaves somewhat differently when you use these buttons. You will have more
consistent success if you use the navigation buttons provided in the administration
GUI. See “Administration GUI Navigation Bar and Buttons” on page 51.
If you have changed any of the information and have not saved your changes, you
will receive a warning message that you have unsaved changes. If you ignore the
warning and move to a different page without returning and saving the changes,
any changes that you have not saved will be lost.
Universal Resource Locator (URL)
Use on of the following URLs to connect to the administration GUI to administer a
Screen or set of Screens remotely:
■
Remote administration – Type http://screenname:3852 as the URL, where
screenname is the name of the Screen that you want to administer.
Use on of the following URLs to connect to the administration GUI to administer a
Screen locally:
■
Local administration – Type http://localhost:3852 as the URL for the
browser.
This is the only time that you need to enter a URL in the Location field of the
browser.
The Administration GUI
The administration GUI for SunScreen is organized as a set of pages. Each page
contains one or more controls. For example, most pages include buttons and text
fields, which you update using your keyboard and mouse.
Logging in as a user with the administrative access level ALL, READ, or WRITE
puts you into a session. You cannot log out of a session if you have made changes,
until you have either saved or cancelled any changes to the last saved version.
Chapter 5
Administration Graphical User Interface
47
Caution – Do not change the administration address (le0, qe0, hme0, and the like),
the administration certificate, the local certificate, or the administration-group
certificate. If you change these items, you risk losing your connectivity from the
Administration Station to the Screen. Reestablishing your connectivity is difficult
and requires that you log into the Screen directly or use an Administration Station
that is still working. It also requires exchanging encryption information
Login Page
The Login page for SunScreen appears when the browser connects to the designated
Screen. FIGURE 5-1 shows the Login page for SunScreen.
The controls on the Login page are explained in TABLE 5-1.
TABLE 5-1
Controls on the SunScreen Login Page
Controls
Description
User Name field
Type your user name. The default user name is admin.
Password field
Type the password associated with your user name. The default user password is
admin. Change the password for the default login account as soon as possible to
prevent unauthorized access to the Screen’s policies. For a description on how to
change passwords, see the section “Changing the Password” on page 51 of this
manual or the SunScreen Administration Guide.
Locale choice list
Choose the locale for localized versions of SunScreen. The default is en_US
[English USA]. This also means that the libraries used to generate messages
are in US English.
Select Task choice list
Choose to start the session by viewing the SunScreen Information page or by
managing policies by starting with the Policies List page.
•The selection View Information opens the SunScreen Information page, which
contains the logs, status information, and statistical information. This is the
default choice.
•The selection Manage Policies opens the Policies List page, on which you see
the active policy and the policies that you have added. From this page, you add
new policies, edit policies, and modify various databases.
Login button
Opens the page that you chose for the Select Task field after successful
authentication.
Documentation button
Displays links to the online SunScreen documentation. Click one of the links to
open the appropriate documentation. You do not have to log
in to look at the online documentation.
48
SunScreen 3.1 Reference Manual • May 2000
Changing the Password
During installation, a default administration user account called admin with the
password admin was created. Change this password as soon as possible to assure
the security of the Screen.
Caution – Do not change the administration address (le0, qe0, hme0, and the like),
the administration certificate, the local certificate, or the administration-group
certificate. If you change these items, you risk losing your connectivity from the
Administration Station to the Screen. Reestablishing your connectivity is difficult
and requires that you log into the Screen directly or use an Administration Station
that is still working. It also requires exchanging encryption information
Online Documentation
You can look at the online documentation by clicking the Documentation button on
the login page, as shown in FIGURE 5-1 or by clicking the Documentation button on
the administration GUI navigation bar, shown in FIGURE 5-1.
SunScreen Information Page
The SunScreen Information page is the default selection in the Select Task field of the
Login page. On this page you can move to the Policies List page, choose the Screen
about which you want information, view the logged information about a Screen’s
performance, check the status of a Screen, and view the SKIP statistics, view the
online documentation, and logout.
Administration GUI Navigation Bar and Buttons
The administration GUI navigation bar and navigation buttons, shown in
FIGURE 5-2, appear at the top of administration GUI pages. You should use these
button for moving among the pages of the administration GUI.
FIGURE 5-2
Administration GUI Navigation Buttons
Chapter 5
Administration Graphical User Interface
49
If these buttons are missing from a page of the administration GUI, it means that
you have unsaved changes from your editing session. Once you have saved your
changes the buttons reappear.
TABLE 5-2 describes the administration GUI navigation buttons.
TABLE 5-2
Administration GUI Navigation Buttons
Control
Description
Logout
Logs out of the administration session, which clears any lock you may be holding.
Policies
Displays the Policies List page, where you add new policies. You can edit the
policies for SunScreen on the Policy Rules page.
Information
Displays the Information page, where you can view the logs, product
information, status of SunScreen, and the SKIP statistics.
Documentation
Displays the Documentation page, which contains links to the online SunScreen
documentation.
The Name of the Screen
You choose the name of the Screen about which you want to view the information
from a choice list. The names of the screens from among which you can choose are
those that are in the centralized management group or HA cluster.
The Log Browser Tabs on the Information Page
Clicking one of these tabs displays the status, logs, and the traffic and SKIP statistics.
Status Tab
The Status tab is displayed by default. The Status tab displays the information
shown in FIGURE 5-3. This information is derived from the system and the
configuration of the firewall when you installed the SunScreen or modified the
configuration. You cannot edit any of the fields on this page.
50
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-3
SunScreen Information Page—Status Tab
TABLE 5-3 describes the information presented on this page.
TABLE 5-3
Status Information
Title
Description
Product
The name of the software product.
System Boot Time
Date and time when the system was last restarted.
SunScreen Boot Time
Date and time when the system was last restarted.
Version
The release of the software that is running.
HA Configured
Whether high availability (HA) is configured (YES or NO).
HA Daemon
Whether the high availability daemon is running (OFF or ON). If the HA daemon is
running, the members of the HA cluster appear in the area below along with the
state of each member of the HA cluster (Active or Passive).
HA Primary Host
The name or IP address of the primary host of the high availability cluster.
Chapter 5
Administration Graphical User Interface
51
TABLE 5-3
Status Information (Continued)
Title
Description
Host Names
Lists the hosts configured for HA. This information appears in the area set off from
the rest of the information and is updated by default every 30 seconds. You can
change the update interval by changing the poll interval in the Logs tab.
Status
Shows the status of the primary and secondary HA hosts. The status is ACTIVE,
PASSIVE, and NON-RESPONSIVE. This information appears in the area set off from
the rest of the information and is updated by default every 30 seconds. You can
change the update interval by changing the poll interval in the Logs tab.
Help button
Displays the online help for this page.
Logs Tab
The logs tab displays the Log Browser panel, as shown in FIGURE 5-4.
52
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-4
SunScreen Information Page—Logs Tab
TABLE 5-4 describes the column headings for the log panel of the SunScreen
Information page.
TABLE 5-4
Column Headings on the Log Panel of the SunScreen Information Page
Field
Description
Time
Indicates the time that the packet or event represented by this record was logged by the
Screen. Use this time field to retrieve records in Historical mode as set in the Log Browser
Tab Retrieval Setting.
Level
Indicates the type and severity level of the logged event.
Service
Indicates the network service or protocol, such as TCP, IP, NFS, Telnet, or HTTP, over which
this packet was sent or to which the event is related.
Chapter 5
Administration Graphical User Interface
53
TABLE 5-4
Column Headings on the Log Panel of the SunScreen Information Page
Field
Description
Address(es)
Shows the address from which and to which a packet was sent. Arrows indicate direction.
Some events that, by themselves, are not related to IP traffic will not have an address or
addresses, as shown in the example.
Reason/Detail
Shows the reason a packet or event was logged or the detail regarding the logging. This
information depends on the requirements of the rules within a policy.
The logs tab also displays the Retrieval Setting tab and Information tab for the logs.
Logged packets are configured in the packet filtering rules so that a packet or an
event is displayed which meets the requirements of a rule in a policy. The log has
two retrieval modes: Historical and Real Time.
■
The Historical mode allows you to examine a particular segment for a particular
time.
■
The Real Time mode displays information as the packets pass through the Screen
while you are looking at the log.
For more information setting the values for the log browser, see the section on the
Retrieval Settings tab below.
Retrieval Setting Tab
FIGURE 5-5 shows the Retrieval Setting tab for the SunScreen Information page and
the log browser in particular. The Filter Keywords, Add to Current Filter, and
Current Filter controls are discussed in greater detail in the following section,
“Setting a Log Viewing Filter.”
Left-Most Editable Combo Box
Left-Center Editable Combo Box
Right-Center Editable Combo Box
Right-Most Editable Combo Box
FIGURE 5-5
54
Retrieval Setting Tab
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-5 describes the controls on the Retrieval Setting tab.
TABLE 5-5
Controls on the Retrieval Setting Tab
Control
Description
Retrieval Mode radio buttons
Specifies the time frame for which you want log messages:
• Historical allows you to examine a particular segment for particular
time and shows the segment of that log the most closely matches the
time that you see as the first item in the list of logged packets. You
must use four digits in specifying the year, for example, 2000.
• Real Time specifies that the system displays the most recently logged
records. You can specify how often the Log Browser page updates the
log display in the Real Time Poll Interval field. If you set the log to Real
Time Poll Interval, click the apply button. Depending upon your
configured settings, records are logged faster than the Log Browser
polls for new records. Thus, the display falls more and more behind as
time goes on. If you want to see the most recently logged records. Click
the Apply button to force a retrieval. The Poll Interval field also sets the
times when the information in the Statistics tab is updated.
Fetch More Records button
Retrieves more log records in the historical mode only. If you check
Historical Reference Time and click the Apply button after specifying a
date and time for retrieving records, the display will retrieve log records
using the date and time that the log file was last cleared. Using this
button, you can display the next screen of later records.
Filter Keywords field
Provide the ability to create many simple filtering expressions from the
choice lists available. These controls reduce typing effort as well as
serving as reminders of filtering options. For more detail, see the
following section, “To Set a Log Viewing Filter.”
Add to Current Filter button
Causes these items chosen in the Filter Keywords fields to be added to
the Filter Keywords text entry box at its current insertion pointer. For
more detail, see the following section, “To Set a Log Viewing Filter.” It
adds all text that is currently selected in the four combo boxes.
Current Filter text box
Allows you to enter an expression of the log-browser filtering language.
An arbitrary logdump expression can be entered there and activated
using the Apply button. For more detail, see the following section, “To
Set a Log Viewing Filter.”
Setting a Log Viewing Filter
The Log Browser filters log events to be displayed. The language that it uses is
identical to the filtering options of the logdump command in the command-line
program; it is a superset of the language used by the Solaris snoop packet monitor
tool.
You have full access to this language typing an arbitrary logdump expression in the
Current Filter text entry box in its Retrieval Settings tab and clicking the Apply
button to activate it.
Chapter 5
Administration Graphical User Interface
55
In addition, the Filter Keywords controls provide the ability to create many simple
filtering expressions. These controls reduce typing effort as well as serving as
reminders of filtering options.
The Filter Keywords controls are used by selecting one or more operations from
their choice lists or entering a target (operand) in the right-most editable combo box.
After this choosing or typing your entry, click the Add to Current Filter button to
add these items to the Filter Keywords text entry box at its current insertion pointer.
The left-most editable combo box contains the Boolean operators and, or, and not.
The left-center editable combo box provides filtering terms that are complete and
restrict the type of log event displayed. TABLE 5-6 describes the terms in the leftcenter editable combo box.
TABLE 5-6
56
Filter Terms of the Left-Center Editable Combo Box
Term
Description
loglvl pkt
Allows displaying network packet-type events
loglvl sess
Allows displaying network session-type events
loglvl auth
Allows displaying events related to authentication operations
loglvl app
Allows displaying events related to screen application (usually proxy)
operations
logapp auth
Allows displaying events from the authentication subsystem
logapp edit
Allows displaying events related to registry or policy editing
logapp ftpp
Allows displaying events from the FTP proxy
logapp log
Allows displaying events related to the logging facilities themselves
logapp httpp
Allows displaying events from the HTTP proxy
logapp smtpp
Allows displaying events from the SMTP proxy
logapp telnetp
Allows displaying events from the Telnet proxy
logsev emerg
Allows displaying events of an emergency severity
logsev alert
Allows displaying events of an alert severity or above
logsev crit
Allows displaying events of a critical severity or above
logsev err
Allows displaying events of an erroneous severity or above
logsev warn
Allows displaying events of a warning severity or above
logsev note
Allows displaying events of a notice severity or above
logsev info
Allows displaying events of an informative severity or above (all
events that are not of debug severity)
logsev debug
Allows displaying events of a debug severity or above (all events)
SunScreen 3.1 Reference Manual • May 2000
The right-center editable combo box provides filtering terms most of which are
incomplete and require an operand value, You type these in the right-most editable
combo box. They are added to the choice list of the right-most editable combo box
for reference so that you need not retype the value if you want to use it again.
TABLE 5-7 describes the filter terms in the right-center editable combo box.
TABLE 5-7
Filter Terms in the Right-Center Editable Combo Box
Term
Description
logwhy reason#
Restricts display to packets that have the given logging reason why
code (See Appendix D, TABLE D-1
logiface iface
Restricts display to packets that arrived on the interface named
iface
host hostname
Restricts display to events either from or to hostname
dst hostname
Restricts display to events destined for hostname
src hostname
Restricts display to events origination from hostname
port hostname
Restricts display to events related to the service svcname
dstport hostname
Restricts display to events targeted to the service svcname
srcport svcname
Restricts display to events originating from the service svcname
net netaddr
Restricts display to events either from or to the network whose
number is netaddr
gateway gwyaddr
Restricts display to packets that used gwyaddr as a gateway
udp
Restricts display to events related to the UDP transport protocol
tcp
Restricts display to events related to the TCP transport protocol
icmp
Restricts display to packets of the ICMP control protocol
rpc
Restricts display to packets of the RPC protocol
etheraddr etheraddr
Restricts display to packets that have arrived from this Ethernet
address
The terms in italics are variables for which you must supply a value or values in the
when you choose this term from the choice list. The values for the variable are as
follow:
■
reason # The reason number is shown in TABLE D-1 in Appendix D.
■
hostname can be:
■
■
■
An IP address (dotted-quad a.b.c.d) (for example, 129.9.9.99)
An IP address range (a.b.c.d..e.f.g.h) (for example,
129.9.9.0..129.9.9.254)
A hostname known to the screen’s naming service (for example, the DNS name
host.your-domain.com)
Chapter 5
Administration Graphical User Interface
57
■
svcname can be:
■
■
■
■
iface can be:
■
■
The IP network number (for example 199.12.200)
gwyaddr can be:
■
■
The name of an interface (for example hme0)
netaddr can be:
■
■
A numeric TCP or UDP port number (for example, 23 for Telnet)
A numeric TCP or UDP port number range (for example, 6000. .6023 for
X windows)
A service name known to the screen’s naming service (for example, domain
found in /etc/services)
The name of an Ethernet address (link-layer address gateway through which
packets are flowing)
etheraddr can be:
■
The 6-octet Ethernet address (for example 8:0:20:A0:EE:E4)
The Information Tab
The log-browser Information tab on the Screen Information page and shown in
FIGURE 5-6, provides the statistics for the current log.
FIGURE 5-6
Information Tab
TABLE 5-8 describes the fields on the Information tab. You cannot edit the fields on
this page.
TABLE 5-8
Fields on the Information Tab
Control
Description
Server Name field
Indicates the name of the Screen to which the Log Browser is connected.
Log current size field (bytes)
Indicates the current size of the log file in bytes on the server.
Log maximum size filed (bytes)
Indicates the maximum size of the log file in bytes on the server.
Last Cleared field
Indicates the date and time the log file was last cleared.
58
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-8
Fields on the Information Tab (Continued)
Control
Description
Cleared By field
Identifies the login name of the administrator who last cleared the log
file.
Log loss count (records) field
Indicates the number of log records that have been thrown away since
the last “clear” operation. Log records are lost if the log grows beyond its
maximum size or if the file system on which the log is written fills before
that maximum is reached. Packets that cannot be logged because the
traffic load exceeds the logger’s ability to store entries are not counted.
Statistics Tab
The Statistics tab, shown in FIGURE 5-7, provides information on traffic and key
statistics. Traffic statistics include data such as input and output, passed or failed,
logged, and bad packets for packets received over the active interfaces. The Statistics
tab is updated according to the setting in the Real Time Poll Interval field on the
Retrieval Setting tab of the Logs Tab.
Chapter 5
Administration Graphical User Interface
59
FIGURE 5-7
SunScreen Information Page—Statistics Tab
The Traffic Statistics panel (top) displays traffic statistics for each interface on the
Screen. TABLE 5-9 describes the fields on the Traffic Statistics panel of the Statistics
tab. The values displayed in these fields cannot be modified.
TABLE 5-9
Controls on the Traffic Statistics Panel of the Statistics Page
Control
Description
Interface field
Name of the interface.
Address field
Address of the interface.
60
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-9
Controls on the Traffic Statistics Panel of the Statistics Page (Continued)
Control
Description
Inputs field
Total number of packets seen on that network interface. This number includes packets
processed by the Screen and intranet traffic. Because this counter records more than just
the number of packets through the interface, the number can be much higher than the
sum of the numbers in the Passes and Drops fields, which record the number of packets
passed and dropped.
Outputs field
Total number of packets passed from other interfaces on the Screen and sent out over this
interface.
Passes field
Number of packets received from another interface, matched to an ALLOW rule exactly,
and sent out over the designated interface.
Logs field
Number of packets that have been logged by the Screen according to the actions in the
active configuration.
Alerts field
Number of SNMP alerts generated because of the traffic on this network interface.
Drops field
Number of packets that have been dropped, either as a result of exactly matching a
DENY rule or as a result of not matching any rule and being dropped as the default
action of the Screen’s interface.
AllocFail field
Error counter for packets lost because of the lack of resources.
NoCanPuts field
Error counter for packets lost because of the lack of stream flow control.
BadPackets field
Error counter for packets lost because of errors.
The SKIP Statistics panel shows the SKIP statistics for the SunScreen.
TABLE 5-10 describes the fields on the SKIP Statistics panel of the Statistics page. The
values displayed in these fields cannot be modified.
TABLE 5-10
Controls on the SKIP Statistics Panel of the Statistics Tab
Control
Description
skip_hdr_bad_versions field
Total number of SKIP headers with invalid protocol versions.
skip_hdr_short_ekps field
Number of SKIP headers with short encrypted packet fields.
skip_hdr_short_mids field
Number of SKIP headers with short MID fields.
skip_hdr_bad_kp_algs field
Number of SKIP headers with unknown cryptographic
algorithms.
V1 skip_hdr_encodes field
Number of SKIP V1 headers encoded.
V1 skip_hdr_decodes field
Number of SKIP V1 headers decoded.
V1 skip_hdr_runts field
Number of SKIP V1 headers with short packets.
V1 skip_hdr_short_nodeids field
Number of SKIP V1 headers with short node identifiers.
IPSP skip_ipsp_decodes field
Number of SKIP V2 headers decoded.
Chapter 5
Administration Graphical User Interface
61
TABLE 5-10
Controls on the SKIP Statistics Panel of the Statistics Tab (Continued)
Control
Description
IPSP skip_ipsp_encodes field
Number of SKIP V2 headers encoded.
IPSP skip_hdr_bad_nsid field
Number of headers with a bad V2 name space identifier.
IPSP skip_hdr_bad_mac_algs field
Number of headers with unknown or bad authentication
algorithms.
IPSP skip_hdr_bad_mac_size field
The number of headers with an authentication error in the
MAC size.
IPSP skip_hdr_bad_mac_val field
The number of headers with an authentication error in the
MAC value.
IPSP skip_hdr_bad_next field
Number of headers with a bad Next Protocol field.
IPSP skip_hdr_bad_esp_spi field
Number of headers with a bad V2 SPI field.
IPSP skip_hdr_bad_ah_spi field
Number of headers with a bad V2 AH SPI field.
IPSP skip_hdr_bad_iv field
Number of headers with a bad V2 initialization vector.
IPSP skip_hdr_bad_short_r_mkeyid field
Number of headers with a short V2 receiver key identifier.
IPSP skip_hdr_bad_short_s_mkeyid field
Number of headers with a short V2 sender key identifier.
IPSP skip_hdr_bad_bad_r_mkeyid field
Number of headers with a bad V2 receiver key identifier.
skip_key_max_idle field
Time, in seconds, until an unused key is reclaimed.
skip_key_max_bytes field
Maximum number of bytes to encrypt before discarding a key.
skip_encrypt_keys_active field
Number of encryption keys in the cache.
skip_decrypt_keys_active field
Number of decryption keys in the cache.
skip_key_lookups field
Total number of key cache lookups.
skip_keymgr_requests field
Total number of key cache misses (key not found).
skip_key-reclaims field
Total number of key entries reclaimed.
skip_hash_collisions field
Total number of table collisions.
The Action Buttons
FIGURE 5-8 shows the action buttons for the SunScreen Information Page. Use these
buttons to control the various actions on the log.
62
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-8
Action Buttons on the SunScreen Information Page
TABLE 5-11 describes the action buttons on the SunScreen Information Page.
TABLE 5-11
Action Buttons on the SunScreen Information Page
Button
Description
Apply button
Applies any changes to the settings for the Log Browser page. You can click the
Apply button to update the data displayed on the Log Browser page in the real
time mode.
Cancel button
Undoes any changes that have not yet been applied.
Defaults button
Resets the Log Browser settings to their default values.
Save Log button
Saves the log file to a local file. If you are using Netscape Navigator or Internet
Explorer, you must use the Java plug-in to save the log to a local file.
Clear Log button
Clears the log file, which clears the log record display area.
Save/Clear Log button
Saves and clears the log file. While the file is being saved, the Screen does not add
records to the log. If you are using Netscape Navigator or Internet Explorer, you
must use the Java plug-in to save the log to a local file.
Help button
Displays a browser window with the online help for the SunScreen Information
Page. Two Help buttons appear on this page. They both display the same online
help.
Help System
The Help button displays context-sensitive help for the page on which you are. It
brings up a new browser window, which you can quit to return to your page or you
can move it aside and keep it open for quick reference.
Chapter 5
Administration Graphical User Interface
63
Policies List Page
You reach the Policies List page by choosing Manage Policies for the Select Task field
on the Login Page before you click the login button or by clicking the Policies button
on the administration GUI’s navigation bar.
You can move to the SunScreen Information page, display the online documentation,
or log out by clicking the appropriate button on the administration navigation bar
The Policies List page, shown in FIGURE 5-9, allows you to add a new policy or to
edit, copy, rename, delete, and backup a particular policy to a local file; to restore a
policy from a local file; and to initialize HA.
The Policies List page identifies the policies that have been stored for a Screen. The
List Policies page has two instructions under the top or navigation bar: “To edit a
policy select one from the table and click the ‘Edit’ button,” and “For other tasks
select from the top panel buttons.”
64
SunScreen 3.1 Reference Manual • May 2000
Administration GUI
Navigation Buttons
Policies List Panel Banner
Contracted Version of a
Policy
Expanded Version of a
Policy
Policies List Panel
Policies List Page Action
Buttons
FIGURE 5-9
Policies List Page
Policies List Panel
Below the Polic ies List banner is a panel consisting of three columns that show:
1. The name – You must click a name of a policy that you want to edit in this
column. The term “-Currently Active-” appears in this column for the active
policy and the name and the version of the active policy appears in the version
column.
2. The version (if present) – The version lists the versions of policies for your
system.
3. The active policy information (if present).
Chapter 5
Administration Graphical User Interface
65
The Policies List panel lists the policies that have been set up for a particular Screen.
The active policy is the first policy in the list of policies and is automatically
highlighted when you first come to this page. You can edit inactive Screen policies
by clicking the name of an entry in the Policies List panel to highlight it, then click
one of the controls at the bottom of the Policies List page.
Types of Policies
The types of policies are:
66
■
Regular Policies – Policies that share common objects with other regular policies.
■
Versioned Policies – A policy with a version number is displayed by clicking the
button next to the regular policy name in the first column of Policies List Panel of
the Policies List Page. Clicking the reverse arrow hides the versions of a policy. A
policy with a version number contains a snapshot of the common objects that are
embedded in the saved policy. The name of the policy contains a dot followed by
an incremental number. The higher the number, the later the version. Versioned
policies cannot be modified, but their rules can be extracted to a new policy.
■
Currently Active Policy – This policy is extracted from the active policy. The
currently active policy cannot be modified. If you click the currently active policy
and highlight it, the edit button retains the (RO) designation to show that it is
read only. A Save As button appears on the Policy Name line on the Packet
Filtering tab of the Policy Rules panel. You can save any modifications to the
currently active policy as a new policy. A Save As button appears on the Common
Objects panel. You can save the common objects of this policy to replace the
current common objects associates with regular policies. FIGURE 5-10 shows these
Save As buttons.
SunScreen 3.1 Reference Manual • May 2000
Administration GUI
Navigation Buttons
Version of Policy Being Ediited
Save As Button
Common Objects Panel
Save As Button
Policy Rules Panel
FIGURE 5-10
Policy Rules Page Showing the Save As Buttons for the Currently Active
Policy
This allows you to make the common objects embedded in this version of the policy
the current common objects, overwriting the existing set of common objects.
This approach allows you to save only the rules part of the versioned policy so that:
■
These rules become the current rules for this policy, for example the rules for
policy Initial.10 can be made the rules for the current version of Initial.
■
You can copy the rule to a new name.
Note – The rules created in this way are used with the current set of common
objects. On verifying this policy, you may have to fix any inconsistencies.
Chapter 5
Administration Graphical User Interface
67
The difference in behavior between Save As and Edit(RO) is that Save As affects the
current policy only and Edit(RO) affects a policy version. With Edit(RO), you have
the additional choice of making the rules the current rules for the policy.
Policies List Page Action Buttons
TABLE 5-12 describes the action buttons for the Policies List page.
TABLE 5-12
Action Buttons on the Policies List Page
Control
Description
Add New button
Opens a dialog box that prompts you for the name of the policy that you want to add.
The name for this new policy appears on the policies list panel. You add the rules for
the new policy on the Policy Rules page.
Edit button
Opens the Policy Rules page for the policy that you have highlighted and allows you
to change the parameters. If the Edit button displays (RO), it means that the policy
that you highlighted is read-only. The read-only mode applies only to the active policy
and the policy versions in the version column:
• You cannot modify an active policy.
• You must click the name (the first column of the policies list
panel) to highlight the policy that you want to edit.
Copy button
Opens a dialog box that prompts you for the new name of the policy to which you
want to copy the information from the policy that you highlighted on the Policies List
panel.
Rename button
Opens a dialog box asking for the new name you want to assign to the selected policy
on the Policies List panel.
Delete button
Opens a dialog box asking you to confirm you want to delete the selected policy on
the Policies List panel.
Activate button
Activates the selected policy on the Policies List panel for the Screen. After you click
the Activate button, the version and active policy information are updated in the
highlighted row.
Backup All button
Opens the Backup All dialog box, which enables copying the policies to a file or
diskette. You cannot use the Backup All button if you are using a browser whose
security restrictions do not allow access to the file system from applets. Most browsers
have plug-in modules that permit you to back up your policies to a local file or
diskette.
The backup medium contains copies of the local identities (the encryption keys and
certificates) and must be stored securely and disposed of securely to avoid
compromising your security.
Restore All button
Opens the Restore All dialog box, which enables restoring the policies from a file or
diskette. The restore operation causes the information from the backup file to
overwrite all current policy information. You cannot use the Restore All button if you
are using a browser whose security restrictions do not allow access to the file system
from applets.
68
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-12
Action Buttons on the Policies List Page (Continued)
Control
Description
Initialize HA button
Opens the Initialize HA dialog box. This dialog box contains the statements that you
need to be connected to the HA primary to perform this operation and that you must
select the interface you would like to be the HA interface for the primary. This dialog
box presents a choice list of all the interfaces available.
Help button
Opens the online help.
Policy Rules Page
FIGURE 5-11 shows the Policy Rules page.
Chapter 5
Administration Graphical User Interface
69
Administration GUI Navigation Buttons
Policy Rules Page Command Buttons
Common Objects Panel
Common Objects Panel Control
Buttons
Policy Rules Panel
Policy Rules Panel Control Buttons
FIGURE 5-11
Policy Rules Page
Administration GUI Navigation Buttons
The topmost area contains the administration GUI navigation buttons. FIGURE 5-2
shows the navigation buttons and TABLE 5-2 describes these buttons.
70
SunScreen 3.1 Reference Manual • May 2000
The Policy Rules Page Command Buttons
The area below the administration GUI navigation buttons contains the command
buttons for the Policy Rules page. These buttons become active when you add or
edit a common object or modify a policy.
FIGURE 5-12 shows the command buttons on the Policy Rules page.
FIGURE 5-12
Policy Rules Page Command Buttons
TABLE 5-13 describes the command buttons on the Policy Rules page.
TABLE 5-13
Policy Rules Page Command Buttons
Command Button
Description
Save Changes
1. Saves any changes you have made to a policy either through the Common Object
panel or through the Policy Rules panel. When this button is active, the Navigation
buttons on the Policy Rules Page disappear. You must click the Save Changes
button before you can move to another page or log out. When you save your
changes, you are prompted to activate your policy.
2. The proxy user, auth user, admin user, Jar signature, and Jar Hash common objects
are automatically saved when they are edited or new objects are added. For these
objects, the change applies immediately and cannot be reversed and the Save
Changes button is greyed out to show that it is inactive.
When you save changes, you are prompted to activate the modified policy. If you
decide not to activate the modified policy now, you can do so later using the Verify
Policy button. (See below in this table.)
Cancel Changes
Cancels any changes made to a policy either through the Common Object panel or
through the Policy Rules panel.
Verify Policy
Verifies a policy that you have created or modified to check that all the rules are valid
and should compile successfully when you activate it. Verifying a policy permits
debugging it without having to activate it. When a policy successfully verifies, you are
prompted to activate it.
The Policy Rules panel displays the rules in a policy and their order. In this panel,
you can write new rules for a policy and edit the rules in a policy. You can establish
rules for Packet Filtering, Administrative Access, NAT, or VPN, using the respective
tab.
Chapter 5
Administration Graphical User Interface
71
Common Objects Panel
Below the command buttons for the page is the Common Objects panel. You use the
controls on this panel to edit or create new common objects for policies and objects
specific to the Screen. FIGURE 5-13 shows the Common Objects panel of the Policy
Rules page
Registry
Version
Number
Common Objects
Choice List
Subtype Choice
List for Adding a
New Common
Object of Chosen
Type
Choice List of
Screens Available
Choice List for the
Subtype of the
Search String
Search
Button
Search String
Editable Text
Field
Results
Choice List
Number of
Results
Indicator
Noneditable
Detail
Text Area
Common-Objects-Panel Control Buttons
FIGURE 5-13
Common-Objects Panel
TABLE 5-14 describes the information, controls, and the buttons in the Common
Objects Panel.
TABLE 5-14
Information
Common Object Information, Controls, and Buttons
Control
Version
Type
72
Description
The version of the registry of common objects that is being used in a
policy. The latest version of the registry is used by all policies. If you
edit the common objects (registry) the word “modified” appears after
the number until you either cancel the changes or save the changes.
Common Object
Choice List
Displays the list of common objects available. You choose the common
object that you want from this list.
Subtype Choice List
for Adding a New
Common Object of
Chosen Type
Displays the choice list of subtypes available for the common object
that you selected. Each common object has it own set of subtypes and
each subtype requires that you provide different information in a
dialog box for that subtype for that common object.
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-14
Common Object Information, Controls, and Buttons (Continued)
Information
Control
Description
Search
Search String
Enter the string for a particular subtype for a common object in this
editable text field. When you click the Search button, all matching
subtypes appear in the Results choice list. Leaving this field blank
returns all entries defined for the selected subtype or local to the
selected Screen. Selecting All in Search on Screens and Search Subtype
Choice with the Search String field empty returns all entries defined.
Search on Screen
Displays a choice list of the Screens that the Administration Station
manages. Selecting a Screen from this list limits the search to common
objects exclusive to that Screen.
Search Subtypes
Display a choice list of the subtypes available for the selected common
object.
Search Button
Starts the search according to the criteria set.
Results
Displays a choice list of available entries that match the criteria.
Found
Show the number of entries in the search that match the criteria.
Detail
Displays the description for the item chosen from the Results choice
list.
Edit Button
Displays the dialog box for the common object selected. Editing a
common object is similar to adding a new one. The difference is that
after you have chosen the common object that you want to edit and
have clicked the Edit button, the dialog box for that common object
contains all the information and you only need to modify the requisite
information.
Delete Button
Displays the Delete dialog box.
Rename Button
Displays the Rename dialog box.
Help Button
Displays online help.
Common Objects
Common objects are the components or data objects that you use to make up policy
rules. Before you write these rules, you add the common objects that you plan to use
in the rules.
After the common objects have been added, they are stored in a database and can be
used over again to create rule sets for additional policies.
Save Is Not Required With Certain Common Objects
The common objects:
Chapter 5
Administration Graphical User Interface
73
■
■
■
■
■
Authorized user
Admin user
Jar signature
Jar hash
Proxy user
that appear in the administration GUI are automatically saved when they are edited
or new objects are added. You do not need to save these objects. Once these objects
are added or edited, the change applies immediately and cannot be reversed. The
Save button in the administration GUI is greyed out to show that it is inactive.
Note – Although the changes made to these objects are saved immediately, they do
not take effect until a policy is activated. The administration GUI edits authorized
users, which are authuser objects; proxy users, which are proxyuser objects; and
Jar signatures and Jar hashes.
Service
Use the service common object to identify network services that a Screen will use to
filter packets. The service common object has two subtypes, single service and
service group.
Note – Adding a new service with new values makes troubleshooting easier than
editing the default values of a service.
Single Service
You add new network services and edit the filtering activities applied when a service
is used in a rule. You add a new single service using the Service dialog box that
appears when you select New Single Service from the Add New combo box in the
Common Objects panel, shown in FIGURE 5-14.
74
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-14
Service Dialog Box for a New Single Service
You control the filtering activities by specifying what packet-filtering engine you
want to use and the various discriminators and parameters applicable to that
filtering engine.
FIGURE 5-15 shows the filter table of the Service dialog box for a new single service.
FIGURE 5-15
Service Dialog Box for a New Single Service with Expanded Filter Table
Chapter 5
Administration Graphical User Interface
75
TABLE 5-15 describes the controls in the Service dialog box for a single service.
TABLE 5-15
Control
Controls for Service Dialog Box for Single Service
Description
Configuration Information
Name
Specifies the name of the service object.
Description
(Optional) Provides a brief description about the service object.
Screen
(Optional) Restricts the service so that it applies to the selected Screen only. The
default (All) means that all Screens recognize this object unless an object exists that has
been specifically defined for a particular Screen and has the same name as the Screen
for which it is defined.
Filter Table Information
Filter Table
Display the parameters for the single services.
1. The Add Filter button Adds a row to the filter table so that you can define
additional forward filters for the service.
2. The Add Port button adds ports for use by the forward filter. This field becomes
active when you click the port field of the filter table.
3. The Delete button the highlighted row in the table. You click a row in the table to
highlight it.
Filter
Identifies the state engine.
Port
Identifies the port number, program number, or type used by the forward filter.
Broadcast
Determines whether the rules in which the service is used allows communication to
broadcast or multicast addresses. If you want the service to work for nonbroadcast
addresses, you must enter a separate table entries for broadcast and nonbroadcast
entries
Parameters
Overrides the default values the selected packet-filter state engine. Each state engine
has a set of parameters; refer to Appendix C for default parameters values and their
meaning.
Reverse
Determines whether the filter applies to packets originating from the host in the To
address of a rule and going to the From address of a rule.
OK Button
Stores the new or changed information and makes the Save Changes command button
active.
Cancel Button
Cancels any new or changed information.
Help Button
Displays the page of online help for this common object.
Service Group
Use the service group to group single services that you want to use together.
FIGURE 5-16 shows the Service dialog box for service group.
76
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-16
Service Dialog Box for Service Group
TABLE 5-16 describes the controls in the Service dialog box for service group.
TABLE 5-16
Controls for Service Group Service Dialog Box
Control
Description
Name
Specifies the name of the service object.
Description
(Optional) Provides a brief description about the service object.
Screen
(Optional) Restricts this service group applies to the selected Screen only. The default (All)
means that all Screens recognize this object unless an object exists that has been specifically
defined for a particular Screen and has the same name as the Screen for which it is defined.
Services List
Identifies the services that do not belong to the service group. Refer to Appendix C,
“Services and State Engines,” for a description of services.
Members List
Identifies the services that belong to the service group.
Add Button
Moves the service selected in the Services list to the Members list, making the service a
member of the specified service group.
Remove Button
Moves the service selected in the Members list to the Services list, removing the service
from the specified service group.
OK Button
Stores the new or changed information and makes the Save Changes command button
active.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Chapter 5
Administration Graphical User Interface
77
Address
Use the address common object to create address objects that define the source and
destination address for a policy rule. If you are adding addresses, the Address dialog
box that appears for a particular subtype is empty. If you are modifying an existing
address, the Address dialog box displays the existing information. Address objects
has three subtypes: host, range and group.
Host
Host is a way to associate an individual host’s IP address with a name for the
address object. FIGURE 5-17 shows the Address dialog box for adding a new host to
the host subtype.
FIGURE 5-17
Address Dialog Box for New Host
TABLE 5-17 describes the controls in the Address dialog box for a new host.
TABLE 5-17
Controls for New Host Address Dialog Box
Control
Description
Name
Specifies the name for the address object.
Description Field
(Optional) Provides a brief descriptive note about the address object.
Screen
(Optional) Restricts this address so that it applies to the selected Screen only.
The default (All) means that all Screens recognize this object unless an object
exists that has been specifically defined for a particular Screen and has the
same name as the Screen for which it is defined.
IP Address/Host Name
Specifies the IP address you want to associate with the address object
identified in the Name list.
Lookup IP Address Button
If SunScreen has access to DNS or NIS, lets you look up host addresses by
host name.
78
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-17
Controls for New Host Address Dialog Box (Continued)
Control
Description
OK Button
Stores the new or changed information and makes the Save Changes
command button active.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Range
Range associates a range of IP addresses with an address object name. For example,
you can associate a name with a specified range of network IP addresses and use
that name to filter traffic to all hosts on that network. FIGURE 5-18 shows the Address
dialog box for adding a new range of addresses to the range subtype.
FIGURE 5-18
Address Dialog Box for New Range
Chapter 5
Administration Graphical User Interface
79
TABLE 5-18 describes the controls for the Address dialog box for new range.
TABLE 5-18
Controls for New Range Address Dialog Box
Control
Description
Name
Specifies the name for the address object.
Description
(Optional) Provides a brief description about the address object.
Screen
(Optional) Restricts this range of addresses so that it applies to the
selected Screen only. The default (All) means that all Screens
recognize this object unless an object exists that has been
specifically defined for a particular Screen and has the same name
as the Screen for which it is defined.
Starting IP Address
Specifies the starting IP address in the range.
Ending IP Address
Specifies the ending IP address in the range.
OK Button
Stores the new or changed information and makes the Save
Changes command button active.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Group
Group is a way to group host addresses, address ranges and other address groups.
By grouping addresses that use similar services and have similar actions, you can
save time when creating rules. FIGURE 5-19 shows the Address dialog box for adding
a new group to the group subtype.
Note – Before you create an address group, you first define the address objects—
single addresses, address ranges, or address groups—that you want to use in the
address group.
80
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-19
Address Dialog Box for New Group
TABLE 5-19 describes the controls for the Address dialog box for new group.
TABLE 5-19
Controls for the New Group Address Dialog Box
Control
Description
Name
Specifies the name for the address object.
Description
(Optional) Provides a brief description about the address object.
Screen
(Optional) Restricts this address group so that it applies to the selected Screen only. The
default (All) means that all Screens recognize this object unless an object exists that has been
specifically defined for a particular Screen and has the same name as the Screen for which it
is defined.
Addresses
Displays the addresses objects that can to be used to create the address group.
Include List
Specifies the address objects that are currently included in the address group. Use the Add
or Remove buttons to modify the list.
Exclude List
Specifies the address objects that are excluded from the address group. For example, you
can create an address group that includes all addresses except as specified in the Exclude
List. Use the Add or Remove buttons to modify the list.
OK Button
Stores the new or changed information and makes the Save Changes command button
active.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Chapter 5
Administration Graphical User Interface
81
Certificate
Use the certificate common object to configure the certificates for the Screen and for
remote hosts that will communicate securely through the Screen.
Note – Changes to the certificate object that pertain to loading into SKIP take effect
immediately without having to be saved. You cannot use the Cancel Changes button
to undo the changes you made. Changes to the certificate object as stored in the
common objects do not take effect immediately and must be save and only take
effect when the policy in which they are used is activated. For example, in adding a
new certificate, (the certificate is created and loaded immediately into SKIP, but the
name has not been saved as part of the common objects and must be saved.
Renaming a certificate only affects the common objects and must be saved.
Generate Screen Certificate
Generate screen certificate generates a certificate for the Screen. FIGURE 5-20 shows
the Certificate dialog box.
FIGURE 5-20
Certificate Dialog Box for Generate Screen Certificate
TABLE 5-20 describes the controls for the Certificate dialog box for generate Screen
certificate.
TABLE 5-20
Controls for the Certificate Dialog Box for Generate Screen Certificate
Control
Description
Name
Specifies a name for the certificate.
82
SunScreen 3.1 Reference Manual • May 2000
Controls for the Certificate Dialog Box for Generate Screen Certificate
TABLE 5-20
Control
Description
Description
(Optional) Provides a brief description about the certificate object.
Screen
Specifies the Screen that recognizes the certificate object. The default is All.
Installed On
(Optional) Specifies the Screen on which the certificate is generated.
Radio buttons
Specifies the strength of encryption that the Screen uses.
Generate New Certificate
Generates the certificate. The Certificate ID field displays the certificate’s
certificate ID.
OK Button
Stores the new or changed information and makes the Save Changes command
button active.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Associate MKID
Associate MKID, also called the certificate ID, assigns a name to a certificate that
exists on another machine. Associate a certificate ID for encrypted communication
between two screens or between a screen and an Administration Station. FIGURE 5-21
shows the Certificate dialog box for Associate MKID.
FIGURE 5-21
Certificate Dialog Box for Associate MKID
Chapter 5
Administration Graphical User Interface
83
TABLE 5-21 describes the controls for the Certificate dialog box for associate MKID.
TABLE 5-21
Controls for Associate MKID Certificate Dialog Box
Control
Description
Name
Specifies the name for the certificate ID object.
Description
(Optional) Provides a brief description about the MKID or certificate ID object.
Screen
Specifies which Screen recognizes the certificate ID object. The default is All.
Specifying a Screen allows you to define packet-filtering rules that encrypt traffic
between any two machines, not just between an Administration Station and a
Screen. Specify the Screen only if you are using Centralized Management. A
common object or policy rule applies to all Screens unless you choose a specific
Screen.
Installed On
(Optional) Used only if you later remove this certificate object from the common
objects. At that time, the SKIP identity that is installed on the Screen will be
removed from the parameter.
Certificate ID
Specifies the certificate ID (hash value) for the certificate that you generated on
the other system.
Radio Buttons
Specifies the strength of encryption that the Screen uses.
Generate New Certificate
Generates the certificate. The Certificate ID field displays the certificate’s
certificate ID.
OK Button
Stores the new or changed information and makes the Save Changes command
button active.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Certificate Group
Certificate group is a way to group single certificates that you want to use together.
FIGURE 5-22 shows the Certificate dialog box for certificate group.
84
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-22
Certificate Dialog Box for Certificate Group
TABLE 5-22 describes the controls in the Certificate dialog box for certificate group.
TABLE 5-22
Controls for Certificate Group Dialog Box
Control
Description
Name
Specifies the name of the certificate object.
Description
(Optional) Provides a brief description about the certificate object.
Screen
Specifies which Screen recognizes the certificate object.
Available Certificate List
Identifies the certificates that do not belong to the certificate group. Refer to
Appendix C, “Services and State Engines,” for a description of services.
Group Members List
Identifies the certificates that belong to the certificate group.
Add Button
Moves the certificate selected in the Available Certificates List to the Group
Members list, making the certificate a member of the specified service group.
Remove Button
Moves the certificate selected in the Group Members list to the Available
Certificates list, removing the certificate from the specified certificate group.
OK Button
Stores the new or changed information and makes the Save Changes command
button active.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Chapter 5
Administration Graphical User Interface
85
Screen
Use the screen common object to edit or add screen objects. You can edit
miscellaneous Screen parameters, SNMP parameters, and mail Proxy parameters for
screen objects that already exist. The algorithms used here are for centralized
management only. FIGURE 5-23 shows the Screen dialog box.
FIGURE 5-23
Screen Dialog Box
In general, edit, rather than create, screen objects because they are automatically
created during installation. Specifying a Screen enables you to define packet-filtering
rules that encrypt traffic between any two machines, not just between an
Administration Station and a Screen.
Note – You must enter the name of the administrative interface of the Screen. The
name must be the name of the administrative interface of the Screen as it is listed in
the naming service or in the /etc/hosts file.
You must create a screen object if you are setting up:
■
■
A high availability (HA) cluster
A centralized management group (CMG)
You create or edit a screen object using the Miscellaneous, Primary/Secondary,
SNMP, and Mail Proxy tabs in the Screen dialog box.
86
SunScreen 3.1 Reference Manual • May 2000
Miscellaneous Tab
FIGURE 5-23 shows the Miscellaneous tab of the Screen dialog box and the
parameters.
TABLE 5-23 describes the controls for the Miscellaneous tab of the Screen dialog box.
TABLE 5-23
Controls for the Miscellaneous Tab of the Screen Dialog Box
Control
Description
Name
Specifies a name for the screen object.
Description
(Optional) Provides a brief description of the screen object.
Log Size
Sets the size of the log in megabytes.
Stealth Network
Specifies the network address for interfaces that are used as stealth interfaces. Set
this parameter if you have used the interface object to designate any Screen
interfaces as stealth interfaces.
Stealth Netmask
Specifies the netmask for interfaces that are used as stealth interfaces. Set this
parameter if you have used the interface object to designate any Screen interfaces
as stealth interfaces.
Allow Routing Traffic
Specifies whether the Screen sends or receives updates to the routing table using
the RIP protocol.
Name Service
Specifies the name service (DNS, NIS, Both, or None) that the Screen will use.
Certificate Discovery
Specifies whether the Screen uses Certificate Discovery.
OK Button
Stores the new or changed information and makes the Save Changes command
button active.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
SNMP Tab
The SNMP tab specifies the interval for SNMP timed status indicator traps and you
can add, edit, or delete SNMP trap receivers.
Note – Use the Action field of the packet-filtering Rule Definition dialog box to
specify actions that generate SNMP alerts. The machine that receives SNMP trap
alerts must not be a remote Administration Station.
FIGURE 5-24 shows the SNMP tab of the Screen dialog box.
Chapter 5
Administration Graphical User Interface
87
FIGURE 5-24
SNMP Tab of the Screen Dialog Box
TABLE 5-24 describes the controls for the SNMP tab on the Screen dialog box.
TABLE 5-24
Controls for the SNMP Tab of the Screen Dialog Box
Control
Description
Name
Specifies a name for the Screen object.
Description
(Optional) Provides a brief description of the Screen object.
SNMP timer interval
(in minutes)
Specifies in minutes when an SNMP trap is emitted. Specifying a time here turns
on the timed status indicator. Specify the time in 1-minute increments. If you do
not set the interval as part of the screen object’s SNMP_TIMER, these traps are not
sent. You cannot configure this trap.
SNMP Receivers
Displays the list of SNMP receivers. You are limited to five receivers.
Add/Delete
(Name/IP address)
1. Specifies the name or the IP address of the SNMP receiver that you want to
add to list when you click the Add button.
2. Specifies the name or the IP address of the SNMP receiver that you want to
delete when you click the Delete button.
Add
Adds the SNMP receiver specified in the Add/Delete (Name/IP address) field to
the list of SNMP receivers shown in the SNMP Receivers field.
Delete
1. Deletes the SNMP receiver specified in the Add/Delete (Name/IP address)
field from the list of SNMP receivers shown in the SNMP Receivers field.
2. Deletes the SNMP receiver highlighted in the SNMP Receivers field.
OK Button
Stores the new or changed information and makes the Save Changes command
button active.
Cancel Button
Cancels any new or changed information
Help Button
Calls up the page of online help for this common object.
88
SunScreen 3.1 Reference Manual • May 2000
The following SNMP traps are supported:
■
■
■
As an action on a packet that matches a particular rule
As a default drop action on an interface
Time status indicator traps
The first two types include the following data:
■
■
■
■
■
■
interface – The SunScreen network interface number on which the packet was
received.
interfaceName – The SunScreen network interface name on which the packet
was received.
errorReason – The reason the alert was generated. (See the sunscreen.mib file
for a complete list of reasons.)
packetLength – The actual length of the packet in bytes.
lengthLogged – The length of the data logged in bytes.
packetData – The packet data.
The SNMP timed status indicator trap uses the same receivers database as other
types of SNMP traps. There is only one database with a maximum of five receivers.
These receivers are specified as variable to the screen object.
To activate the timed status indicator traps, set the SNMP timer interval.
The following data are in the SNMP timed status indicator. These data cannot be
modified and new data cannot be added:
■
■
■
■
■
■
■
■
■
■
■
■
cpuUsage – Average percentile CPU usage
memoryAvail – Current swap space available, in kilobytes
swapIn – Current swap ins
swapOut – Current swap outs
scanRate – Current scan rate
tcpUsage – Current number TCP connections in the SunScreen state table
ipUsage – Current number IP connections in the SunScreen state table
udpUsage – Current number UDP connections in the SunScreen state table
rootUsage – Disk usage of the root partition, /
varUsage – Disk usage of the var partition, /var
etcUsage – Disk usage of the etc partition, /etc
tmpUsage – Disk usage at the tmp partition, /tmp
Only these SNMP traps are supported. No get or set operations are supported.
Primary/Secondary Tab
The Primary/Secondary tab associates a certificate object with a Screen that is part of
an HA cluster or a CMG. The High Availability choice (No, Primary, or Secondary)
and the Primary Name choice determine the role a Screen has within an HA cluster
Chapter 5
Administration Graphical User Interface
89
and centralized management group (CMG). The settings you choose determine
which other controls on the Primary/Secondary tab are active. FIGURE 5-25 shows the
Primary/Secondary tab of the Screen dialog box.
FIGURE 5-25
Primary/Secondary Tab on the Screen Dialog Box
TABLE 5-25 describes the controls for the Primary/Secondary tab.
TABLE 5-25
Controls for the Primary/Secondary Tab of the Screen Dialog Box
Control
Description
Name
Specifies a name for the Screen object.
1. The entry in the Name field must be the same as the entry that exists in the
nameservice lookup or in the /etc/hosts file. The IP address
associated with this name must match the IP address of the administrative
interface.
2. The type of interfaces must be the same on all the machines in the HA
cluster. This interface must be dedicated on each machine in the HA cluster
with a dedicated network connection. For reasons of security, the HA
network should not be connected to any other network. The HA primary
Screen is always the Screen you administer whether it is the active or
passive Screen.
Description
(Optional) Provides a brief description of the Screen object.
High Availability
Specifies whether the Screen is used for HA. If you are using it for HA, you
can specify whether the Screen is a primary HA Screen or a secondary HA
Screen.
90
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-25
Controls for the Primary/Secondary Tab of the Screen Dialog Box (Continued)
Control
Description
Primary Name
Specifies the name of the primary Screen. This is the primary of this Screen if
this Screen is an HA secondary, or the primary of a centralized management
group if you want this Screen to be a CMG secondary.
Administrative IP
IP address of the Screen that is used for administration. This is the IP address
or an address group that contains all interface addresses of the Screen.
Administration Certificate
Specifies the name of the Screen’s Administration certificate.
High Availability IP Address
Specifies the IP address of the HA interface.
Ethernet Address
Generated by the system.
Key Algorithm
• Specifies the key encryption algorithm that will be used. The options
available depend upon the strength of the encryption installed.
Data Algorithm
• Specifies the key encryption algorithm that will be used. The options
available depend upon the strength of the encryption installed.
MAC Algorithm
Specifies the MAC (authentication) algorithm that will be used. The options
are:
• none
• MD5
• MD5-NAT
OK Button
Stores the new or changed information and makes the Save Changes
command button active.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Mail Proxy
The Mail Proxy tab allows adding, editing, or deleting domains known to distribute
unsolicited electronic mail (spam). You can define spam domains if you use an
SMTP proxy.
FIGURE 5-26 shows the Mail Proxy tab of the Screen dialog box.
Chapter 5
Administration Graphical User Interface
91
FIGURE 5-26
Screen Dialog Box Showing the Mail Proxy Tab
TABLE 5-26 describes the controls for the Mail Proxy tab of the Screen dialog box.
TABLE 5-26
Controls for the Mail Proxy Tab of the Screen Dialog Box
Control
Description
Name
Specifies a name for the Screen object.
Description
(Optional) Provides a brief description of the Screen object.
Spam Domains
Lists the domains that are distributing unsolicited electronic mail.
Add/Delete Host
1. Specify the domain that you want to add to the Spam Domains list when you click
the Add button.
2. Specify the domain that you want to delete from the Spam Domains list when you
click the Delete button.
Add
Adds the domain specified in the Add/Delete Host field to the list of spam domains
shown in the Spam Domains field.
Delete
1. Deletes the domain specified in the Add/Delete Host field from the list of domains
shown in the Spam Domains field.
2. Deletes the domain highlighted in the Spam Domains field.
OK Button
Stores the new or changed information and makes the Save Changes command button
active.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
92
SunScreen 3.1 Reference Manual • May 2000
Interface
The interface common object defines interfaces and specifies the actions a Screen
should take when a packet that is received on that interface is rejected.
FIGURE 5-27 shows the Interface Definition dialog box.
FIGURE 5-27
Interface Definition Dialog Box
TABLE 5-27 describes the controls for the Interface Definition dialog box.
TABLE 5-27
Controls for the Interface Definition Dialog Box
Control
Description
Interface
Specifies the interface.
Type
Specifies the type of interface. The options are:
• ROUTING
• ADMIN
• DISABLED
• HA
• STEALTH
Screen
Specifies the Screen on which this interface physically resides. If you are using
centralized management, you must complete this field.
Address Group
Specifies the source IP addresses for this interface.
Chapter 5
Administration Graphical User Interface
93
TABLE 5-27
Controls for the Interface Definition Dialog Box (Continued)
Control
Description
Logging
Identifies the disposition of a packet, when a packet received on the interface does not
match any rule. The options are:
• NONE – Do not log packets.
• SUMMARY – Record the first 40 bytes of the packet in the log.
• DETAIL – Record the complete packet in the log.
If a packet matches a rule, it is disposed of according to the action for the rule it
matches.
SNMP Alerts
Specifies whether the Screen should issue an SNMP alert message when a packet
received on an interface does not match a rule. The options are:
• SNMP_NONE – Do not send an SNMP alert message. (This is the default.)
• SNMP – Send an SNMP alert message when a packet received on this interface is
rejected.
If a packet matches a rule, it is disposed of according to the action for the rule it
matches.
ICMP Action
Identifies the ICMP rejection message that is issued if a packet received on the
interface is rejected. In most cases, the Screen rejects packets by sending an ICMP
Destination Unreachable packet with the reject code set as specified in the ICMP
action on the interface.
The one exception is the PORT_UNREACHABLE ICMP action. In this case, the Screen
rejects TCP packets by sending a TCP RESET packet and other packets by sending an
ICMP Destination Unreachable (Port Unreachable) message.
The options for the actions are:
• NONE
• NET_UNREACHABLE
• HOST_UNREACHABLE
• PORT_UNREACHABLE
• NET_FORBIDDEN
• HOST_FORBBIDEN.
If a packet matches a rule, it is disposed of according to the action for the rule it
matches.
Comment
(Optional) Provides a descriptive note about the Interface object.
Router IP Address
(Optional) Specifies the router’s IP address when the type of interface is STEALTH.
This allows packets that have had their destination address changed, for example
NAT or tunnelling, to be sent to a router. You can specify as many as five router IP
addresses. If you have stealth interfaces, define the router that does the routing for the
subnet for at least one of them.
OK Button
Stores the new or changed information and makes the Save Changes command button
active.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
94
SunScreen 3.1 Reference Manual • May 2000
Proxy User
The proxy user common object contains the mapping information for users of
SunScreen proxies. The proxy user object has the subtypes single and group. FTP
and Telnet rules reference the proxy user entries.
The proxy user object is automatically saved when it is edited or a new proxy user
object is added. Any changes apply immediately and cannot be reversed. The Save
Changes button is greyed out to show that it is inactive.
Single
The single dialog box defines a new single proxy user.
If you want to use the authentication feature of the FTP and Telnet proxies, you must
define an authorized user before you add a proxy user.
FIGURE 5-28 shows the Proxy User dialog box for adding a new single proxy user.
FIGURE 5-28
Proxy User Dialog Box for a Single Proxy User
Chapter 5
Administration Graphical User Interface
95
TABLE 5-28 describes the controls for the Proxy User dialog box for a single proxy
user.
TABLE 5-28
Controls for the Proxy User Dialog Box for a Single Proxy User
Control
Description
Name
Specifies the name of the proxy user.
Description
Adds a brief description of the proxy user.
User Enabled
Controls whether the user can log into the Screen. This function permits the
administrator to refuse login privileges to someone who previously could log in
without having to remove that person from the list of proxy users.
Authorized User Name
Selects the name of the authorized user to be used to authenticate this proxy user.
Names in this list are generated when you add an authorized user object. If this
field is empty, authorization is not required for this user.
Proxy User Group
Identifies the user group or groups to which the user belongs. If no groups are
highlighted, user does not belong to any group.
Backend User Name
Identifies the user on a specific server. It defaults to the user name.
OK Button
Stores the new or changed information.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Group
The group is a way to group proxy users that have the same privileges. Group proxy
users to save time when creating rules. Before creating a proxy user group, define
the proxy user objects for that proxy user group. Group proxy users to save time
when creating rules.
FIGURE 5-29 shows the Proxy User dialog box for adding a new group.
96
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-29
Proxy User Dialog Box for Grouping Proxy Users
TABLE 5-29 describes the controls for the Proxy User dialog box for grouping proxy
users.
TABLE 5-29
Controls for the Proxy User Dialog Box for Grouping Proxy Users
Control
Description
Name
Specifies the name of the proxy group.
Description
Adds a brief description of the proxy group.
User Enabled
Controls whether this group of proxy users can log into the Screen’s proxy. This function
permits the administrator to refuse login privileges to a group that previously could log in
without having to remove that group from the list of member users.
Proxy Users
Displays the proxy user objects that can to be used to create the member user list for the
proxy user group.
Member Users
Specifies the proxy user objects that are currently included in the member users list of the
proxy user group. Use the Add or Remove buttons to modify the member users list.
OK Button
Stores the new or changed information.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Chapter 5
Administration Graphical User Interface
97
Authorized User
The common object authorized user specifies the users that are allowed to use the
Telnet and FTP proxies.
The common object authorized user is automatically saved when it is edited or a
new authorized user object is added. Any changes apply immediately and cannot be
reversed. The Save Changes button is greyed out to show that it is inactive.
FIGURE 5-30 shows the User dialog box for an authorized user object. This same
dialog box also appears for the administrative user object.
FIGURE 5-30
User Dialog Box for an Authorized User
TABLE 5-30 describes the controls for the User dialog box for an authorized user object
and for an administrative user object.
TABLE 5-30
Controls for the User Dialog Box for an Authorized User Object and
an Administrative User Object
Control
Description
User Name
Specifies the login name of the authorized user.
Description
(Optional) Provides a brief description about the authorized user.
User Enabled
Controls whether the user can log into the Screen’s proxy. This function permits the
administrator to refuse login privileges to someone who previously could log in
without having to remove that person from the list of proxy users.
Password
Specifies the login password for the authorized user.
98
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-30
Controls for the User Dialog Box for an Authorized User Object and
an Administrative User Object (Continued)
Control
Description
Retype Password
Specifies the login password for the authorized user. The password typed in this field
must exactly match the password you typed in the Password field.
SecurID Name
(Optional) Specifies the user’s login name for SecurID authorization.
Real Name
(Optional) Identifies the real name of the authorized user.
Contact Information
(Optional) Displays information on how to contact the specified user.
OK Button
Stores the new or changed information.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Administrative User
The common object administrative user identifies the SunScreen administrators that
have access to the Screen. This object refers to an authorized user; therefore, the
administrative user object uses the same User dialog box that the authorized user
object does.
FIGURE 5-30 shows the User dialog box for both an authorized user object and an
administrative user object. TABLE 5-30 describes the controls for the User dialog box
for both an authorized user object and an administrative user object.
The administrative user object is automatically saved when it is edited or a new
administrative user object is added. Any changes apply immediately and cannot be
reversed. The Save Changes button is greyed out to show that it is inactive.
After you create an administrative user object, you grant administrative access by
creating a rule in the Administrative Access tab of the Policy Rules panel. The name
that you create for the administrative user object is the same name that you use
when you create administrative access rules.
Jar Signature
The Jar signature common object identifies the Java archives (JARs) that you want
the Screen to pass. JAR signatures apply only to the HTTP proxy.
The Jar signature object is automatically saved when it is edited or a new Jar
signature object is added. Any changes apply immediately and cannot be reversed.
The Save Changes button is greyed out to show that it is inactive.
FIGURE 5-31 shows the Jar Signature dialog box.
Chapter 5
Administration Graphical User Interface
99
Jar Signature Dialog Box
FIGURE 5-31
TABLE 5-31 describes the controls for the JAR signature dialog box.
Controls for the Jar Signature Dialog Box
TABLE 5-31
Control
Description
Name
Identifies the name of the certificate.
Master Key ID
Identifies the certificate ID.
Load Jar Certificate Button
Loads the certificate used to authenticate the Java archive. This procedure
requires that your browser can allow local access to files.
OK Button
Stores the new or changed information.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Jar Hash
The HTTP proxy can be set up to filter the Java applets based on the hash value of
the Jar file.
The Jar hash object is automatically saved when it is edited or a new Jar hash object
is added. Any changes apply immediately and cannot be reversed. The Save
Changes button is greyed out to show that it is inactive.
FIGURE 5-32 shows the Jar Hash dialog box.
100
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-32
Jar Hash Dialog Box
TABLE 5-32 describes the controls for the Jar hash dialog box.
TABLE 5-32
Controls for the Jar Hash Dialog Box
Control
Description
Name
Identifies the name of the certificate.
Master Key ID
Identifies the certificate ID.
OK Button
Stores the new or changed information.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
Time
The time common object specifies the time of day and the day of the week that a rule
applies.
FIGURE 5-33 shows the Time dialog box.
Chapter 5
Administration Graphical User Interface
101
FIGURE 5-33
Time Dialog Box
TABLE 5-33 describes the controls in the Time dialog box.
TABLE 5-33
Controls for the Time Dialog Box
Control
Description
Name
Specifies a name for the time object.
Description
(Optional) Adds a descriptive note about the time object.
Screen
Specifies the Screen that recognizes the time object.
Table for the Time Parameters
Sets the time of day and the day of the week for this time object. Use the
Add button to add a row to the table and the Delete button to remove a row
to the table
1. Day column contains a choice list of the days of the week plus
EVERYDAY and *.
2. Start Time column contains a choice list of the hours in a day using the
24–hour clock with midnight denoted as 00.
3. Time Start column contains a choice list of the minutes in an hour in
5–minute increments.
4. End Time column contains a choice list of the hours in a day using the
24–hour clock with midnight denoted as 00.
5. End Time column contains a choice list of the minutes in an hour in 5–
minute increments.
Add Row Button
Adds a row to the table so that you can set time parameters for this time
object. To cover more than one day, but less than everyday, add a row for
each day and choose the day that you want for each row
Delete Button
Deletes a highlighted entry in the table.
OK Button
Stores the new or changed information and makes the Save Changes
command button active.
Cancel Button
Cancels any new or changed information.
Help Button
Calls up the page of online help for this common object.
102
SunScreen 3.1 Reference Manual • May 2000
Policy Rules Panel
Policy rules govern data communication between systems—either another host, a
network, or a remote computer and your network. You write and edit the rules that
govern this communication in the Policy Rules panel. SunScreen uses ordered sets of
rules to implement the security policies. Ordered set of rules means that, when a
Screen receives a packet, it matches the packet against each rule in its active policy
until it finds one that applies, and then takes the actions associated with that rule.
Once a Screen finds an applicable rule for a packet, it ignores subsequent rules in its
active policies.
Rules do not take effect until you save and activate the policy to which they belong
by clicking the Save Changes button located above the Common Objects area, and
the Activate button in the bottom area of the Policies List page. SunScreen sets up
the basic security policy for name service lookups, Routing Information Protocol
(RIP) packets, and SunScreen SKIP certificate discovery during installation. You can
change these setting for each Screen by changing them in the screen object. You can
use the Rules area on the Policy Rules page to specify how your Screen should filter
other types of packets.
Note – If the specified filtering rule fails to detect any issued certificate (key)
encryption algorithms, it may display the following error message:
An error occurred in detecting the
Encryption algorithms.
Please check if skipd process is running.
If this occurs, restart the skipd process using the command skipd_restart.
Use the Policy Rules panel to add or modify a rule in a SunScreen policy. Clicking
the Add New button (or selecting a policy and clicking the Edit button) opens the
Policy Rules panel of the Policy List page.
To display the controls on a tab, click the tab header. TABLE 5-34 describes the tabs
that are available from the Policy Rules panel.
TABLE 5-34
Policy Rules Panel Tabs
Tab
Description
Packet Filtering
Shows the packet filtering rule or rules.
Administration Access
Defines access rules for local administration and remote
Administration Stations through the administration GUI or the
command line (see Appendix B).
NAT (Network Address Translation)
Maps private network addresses to public network addresses.
VPN (Virtual Private Network)
Maps name, address, certificate, issued certificate (key) algorithm,
data algorithm, MAC algorithm, tunnel address, and description.
Chapter 5
Administration Graphical User Interface
103
Packet Filtering Tab
The Packet Filtering tab displays a panel, shown in FIGURE 5-34, for configuring
packet-filtering rules. Use packet filtering to control traffic using a particular service,
traffic intended for a particular service, or traffic coming from a particular address.
FIGURE 5-34
Packet Filtering Tab
SunScreen uses ordered packet filtering. The Screen assumes that the first rule that
matches a packet is the rule that governs the disposition of the packet.
If the packet does not match any rule, the Screen uses its default action to determine
the disposition of the packet.
Note – The default action is set when defining the interfaces. A default action can be
set for each interface, but not for the entire Screen. Typically, the default action is to
only drop the packet. Other options are available. See “Interface” on page 95.
104
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-35 describes the available fields in the Packet Filtering tab.
TABLE 5-35
fields on the Packet Filtering Tab
Field
Description
Rule Index
(Optional) Assigns a number to a rule. When editing or adding a new rule, by default, this
field displays a number one greater than the last rule (indicating this rule will be placed at
the bottom of the list). If you type a lower number, the new rule is inserted into the specified
position in the list, and the rules currently in the configuration are renumbered.
Screen
(Optional) Specifies the Screen for which you want the rule to apply. Type a specific Screen
name in this field if you use centralized management and want a rule to apply to a specific
Screen.
Service
Identifies the network service or service group to which this rule applies. Network services
and service groups are described in Appendix C, “Services and State Engines.”
Source
The value to which the source address of a packet is compared. If an asterisk (*) appears, any
source address meets the criteria of the rule.
Destination
The value to which the destination address of a packet is compared to determine whether the
rule should apply. If an asterisk (*) appears, any destination address meets the criteria of the
rule.
Action
Displays the action for the rule and permits setting the logging behavior. The options are:
• ALLOW
• DENY
• ENCRYPT
• SECURE
Time
Specifies the time of day for the rule.
Description
(Optional) Provides a brief description of the Administrative Access rule.
To edit every field, except the Rule Index field, on the Packet Filtering tab, click it to
display the choice list. The changes in the fields for a rule are reflected in the
Common Objects panel, except for the Action field, which displays a dialog box for
that rule and policy. Set the logging options for the action in the dialog box for that
action. The particular dialog box that appears depends on the action selected.
ALLOW Action
FIGURE 5-35 shows the Policy Rule Index dialog box for the ALLOW action.
Chapter 5
Administration Graphical User Interface
105
FIGURE 5-35
Policy Rule Index Dialog Box for ALLOW action
TABLE 5-36 describes the controls in Policy Rule Index dialog box for ALLOW action.
TABLE 5-36
Controls for ALLOW Action
Control
Description
Log
Sets logging behavior. The options are:
• LOG_NONE – Do not log packets.
• LOG_SUMMARY – Record the first 40 bytes of the packet in the log.
• LOG_DETAIL – Record the complete packet in the log.
• LOG_SESSION – Record information about the session in the log. The information saved
consists of the source and destination addresses and ports (if applicable), the amount of data
being sent in each direction, and the length of the session. Not used for stateless services such
as ip all.
SNMP
Specifies whether the Screen should issue an SNMP trap message when the rule is applied. The
options are:
• SNMP_NONE – Do not send an SNMP alert message when a packet matches the criteria of this
rule.
• SNMP – Send an SNMP alert message when a packet matches the criteria of this rule.
PROXY
Specifies the proxy the Screen should use, if any, when a packet meets the selection criteria of the
rule. The options are:
• NONE
• PROXY_HTTP
• PROXY_FTP
• PROXY_SMTP
• PROXY_telnet
If you choose a proxy, another dialog box, according to the proxy chosen, is displayed.
■
106
PROXY_HTTP – Presents the dialog box shown in FIGURE 5-36.
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-36
PROXY_HTTP Dialog Box for ALLOW action
TABLE 5-37 lists the flags for the HTTP proxy.
TABLE 5-37
HTTP Proxy Flags
Flag
Function
Cookies
Permits the use of cookies. The options are:
• ALLOW
• DENY
ActiveX
Permits the use of ActiveX. The options are:
• ALLOW
• DENY
Java
Allow or disallow use of Java applets. The options are:
• Allow JAVA
• Block JAVA
• JAR Signature
• JAR Hash
• JAR Signature and Hash
SSL
Permits the use of SSL encryption. The options are:
• ALLOW
• DENY
■
PROXY_FTP – Presents the dialog box shown in FIGURE 5-37.
Chapter 5
Administration Graphical User Interface
107
FIGURE 5-37
PROXY_FTP Dialog Box for ALLOW action
TABLE 5-38 lists the settings available for the flags for the FTP proxy.
TABLE 5-38
FTP Proxy Flags
Flag
Function
GET
Allow or disallow use of the FTP get command
PUT
Allow or disallow use of the FTP put command
CHDIR
Allow or disallow use of the FTP chdir command
MKDIR
Allow or disallow use of the FTP mkdir command
RENAME
Allow or disallow use of the FTP rename command
REMOVE
Allow or disallow use of the FTP remove_dir command
DELETE
Allow or disallow use of the FTP delete command
PROXY USERS
Choose the proxy user or the group of proxy users that you want for this rule. You can have
only one proxy user or one group of proxy users in this field. You define these proxy users
in the proxy user common object.
■
108
PROXY_SMTP – Presents the dialog box shown in FIGURE 5-38.
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-38
PROXY_SMTP Dialog Box for ALLOW action
The only flag for the SMTP proxy is to allow or disallow relayed mail.
■
PROXY_Telnet – Presents the dialog box shown in FIGURE 5-39.
FIGURE 5-39
PROXY_Telnet Dialog Box for ALLOW action
For the PROXY USER field, type the proxy user or the group of proxy users that you
want for this rule from the choice list. Specify only one proxy user or one group of
proxy users in this field. Define these proxy users in the proxy user common object.
DENY Action
FIGURE 5-40 shows the Policy Rule Index dialog box for DENY action
Chapter 5
Administration Graphical User Interface
109
FIGURE 5-40
Policy Rule Index Dialog Box for DENY Action
TABLE 5-39 describes the controls in Policy Rule Index dialog box for DENY action.
TABLE 5-39
Controls for DENY Action
Control
Description
Log
Sets logging behavior. The options are:
• LOG_NONE – Do not log packets.
• LOG_SUMMARY – Record the first 40 bytes of the packet in the log.
• LOG_DETAIL – Record the complete packet in the log.
SNMP
Specifies whether the Screen should issue an SNMP trap message when the rule is applied.
The options are:
• SNMP_NONE – Do not send an SNMP alert message when a packet matches the criteria
of this rule.
• SNMP – Send an SNMP alert message when a packet matches the citeria of this rule.
ICMP Reject
Identifies the ICMP rejection message issued when the rule is applied. In most cases, the
Screen rejects packets by sending an ICMP Destination Unreachable packet with the reject
code set as specified in the ICMP action in the rule.
The one exception is the PORT_UNREACHABLE ICMP action. In this case, the Screen
rejects TCP packets by sending a TCP RESET packet and other packets by sending an ICMP
Destination Unreachable (Port Unreachable) message.
The options for the actions are:
• NONE
• NET_UNREACHABLE
• HOST_UNREACHABLE
• PORT_UNREACHABLE
• NET_FORBIDDEN
• HOST_FORBIDDEN
110
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-39
Controls for DENY Action (Continued)
Control
Description
PROXY
Specifies the proxy you want to use, if any. The options are:
• NONE
• PROXY_HTTP
• PROXY_FTP
• PROXY_SMTP
• PROXY_telnet
If you choose a proxy, another dialog box, according to the proxy chosen, is displayed.
PROXY USERS
You must type the name or names of the proxy users in this field. You find the proxy users
by selecting proxy user as the type of object and searching for them in Common Objects
panel of the Policy Rules page.
■
■
PROXY_HTTP – Presents the same dialog box shown in FIGURE 5-40 save that
PROXY_HTTP appears in the PROXY field. There are no flags to set.
PROXY_FTP – Presents the dialog box shown in FIGURE 5-41.
FIGURE 5-41
■
■
PROXY_FTP Dialog Box for DENY action
PROXY_SMTP – Presents same dialog box shown in FIGURE 5-40 save that
PROXY_SMTP appears in the PROXY field. There are no flags to set.
PROXY_Telnet – Presents the dialog box shown in FIGURE 5-42.
Chapter 5
Administration Graphical User Interface
111
FIGURE 5-42
PROXY_Telnet Dialog Box for DENY action
ENCRYPT Action
FIGURE 5-43 shows the Policy Rule Index dialog box for ENCRYPT action.
112
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-43
Policy Rule Index Dialog Box for ENCRYPT Action
TABLE 5-40 describes the controls in Policy Rule Index dialog box for ENCRYPT
action.
TABLE 5-40
Controls For ENCRYPT Action
Control
Description
Log
Sets logging behavior. The options are:
• LOG_NONE – Do not log packets.
• LOG_SUMMARY – Records the first 40 bytes of the packet in the log.
• LOG_DETAIL – Records the complete packet in the log.
• LOG_SESSION – Records information about the session in the log. The
information saved consists of the source and destination addresses and ports
(if applicable), the amount of data being sent in each direction, and the length
of the session. Not used for stateless services such as ip all.
SNMP
Specifies whether the Screen should issue an SNMP trap message when the rule
is applied. The options are:
• SNMP_NONE – Do not send an SNMP alert message when a packet matches
the criteria of this rule.
• SNMP – Send an SNMP alert message when a packet matches the criteria of
this rule.
Chapter 5
Administration Graphical User Interface
113
TABLE 5-40
Controls For ENCRYPT Action (Continued)
Control
Description
Encryption
Specifies the version of SKIP. The options are:
• SKIP_VERSION_1 – Use old-style SKIP to encrypt or decrypt packets.
• SKIP_VERSION_2 – Use new-style SKIP to encrypt or decrypt packets.
Source Tunnel
Specifies the tunnel address of the from encryptor.
Destination Tunnel
Specifies the tunnel address of the to encryptor.
From Encryptor
Specifies the certificate name for the SKIP host that is encrypting the data. This
can be either a Screen or an end-system SKIP host. Either the From Encryptor or
the To Encryptor must identify a SKIP certificate on the local Screen
To Encryptor
Specifies the certificate name for the SKIP host that is decrypting the data. This
machine can be the local Screen or a remote host.
Key Algorithm
Specifies the type of encryption you want to use for traffic. The options available
depend on the strength of encryption that you are using.
Data Algorithm
Specifies the type of encryption you want to use for data. The options available
depend on the strength of encryption that you are using.
MAC Algorithm
Specifies the type of authentication that you want to use for packets that meet
the criteria of this rule. The MAC algorithm is supported in SKIP version 2. The
options are:
• none
• MD5
• MD5-NAT
SECURE Action
FIGURE 5-44 shows the Policy Rule Index dialog box for SECURE action
FIGURE 5-44
114
Policy Rule Index Dialog Box for SECURE Action
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-41 describes the controls in Policy Rule Index dialog box for SECURE action.
TABLE 5-41
Controls for SECURE Action
Control
Description
Log
Sets logging behavior. The options are:
• LOG_NONE – Do not log packets.
• LOG_SUMMARY – Record the first 40 bytes of the packet in the log.
• LOG_DETAIL – Record the complete packet in the log.
• LOG_SESSION – Record information about the session in the log. The information saved consists
of the source and destination addresses and ports (if applicable), the amount of data being sent in
each direction, and the length of the session. Not used for stateless services such as ip all.
SNMP
Specifies whether the Screen should issue an SNMP trap message when the rule is applied. The
options are:
• SNMP_NONE – Do not send an SNMP alert message when a packet matches the criteria of this
rule.
• SNMP – Send an SNMP alert message when a packet matches the criteria of this rule.
VPN
Specifies the name of the VPN to which the rule applies.
Administrative Access Tab
The Administrative Access rules tab shows access and encryption settings for local
and remote administration. FIGURE 5-45 shows the Administrative Access tab.You set
the values reflected on the two panels of this tab through the dialog box for each
panel.
FIGURE 5-45
Administrative Access Tab
Chapter 5
Administration Graphical User Interface
115
Access Rules for GUI Local Administration
Use the Access Rules for GUI Local Administration dialog box, shown in FIGURE 5-46,
to add or modify administrative access rules for local Administration Stations.
FIGURE 5-46
Local Access Rules Dialog Box
TABLE 5-42 describes the controls for the Local Access Rules dialog box.
TABLE 5-42
Controls for the Local Access Rules Dialog Box
Control
Description
Rule Index
Assigns a number to a rule. By default, this field displays a number one greater than
the last rule (indicating this rule will be placed bottom of the list). If you type a lower
number, the new rule is inserted into the specified position in the list, and the rules
currently in the configuration are renumbered.
Screen
(Optional) Specifies the Screen for which you want the rule to apply. Type a specific
Screen name in this field if you use centralized management and want a rule to apply
to a specific Screen. The default All applies to all Screens.
User
Lists the user names of SunScreen administrators. Use the names that you defined for
the Administrative User object.
116
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-42
Controls for the Local Access Rules Dialog Box (Continued)
Control
Description
Access Level
Specifies what actions the designated user can perform.
1. ALL – Allows the administrator to display and modify all setting for the Screen.
2. WRITE – The administrator can perform all operations except modifying the
Administration Access rules for any Policy.
3. READ – The administrator can view both the Information and Policy. This level
also allows the user to save and clear logs on the information page. With this access
level users cannot modify any Policy data.
4. STATUS – The administrator can display status information (logs, statistics, status
information) but cannot display or modify management settings.
5. NONE – The administrator no longer has any access. This switch prevents an
administrator who had access from logging in without having to remove that
administrator from the database.
Description
(Optional) Provides a brief description of the Administrative Access rule.
Move
Allows you to assign a new rule index number for the rule that you highlighted in the
Access Rules for GUI Local Administration panel of the Administrative Access tab.
Delete
Deletes the access rule that you highlighted in the Access Rules for GUI Local
Administration panel of the Administrative Access tab.
Help
Displays the online help.
The Access Rules for Remote Administration
Use the Remote Access Rules dialog box, shown in FIGURE 5-47, to add or modify
administrative access rules for remote administration stations. The certificates used
here must be of the same strength and type as those defined in the screen object. The
entries here determine what type of remote Administration Station the Screen will
accept. The Screen only uses the administration certificate field of the Screen object
here.
Chapter 5
Administration Graphical User Interface
117
FIGURE 5-47
Remote Access Rules Dialog Box
TABLE 5-43 describes the controls for the Remote Access Rules dialog box.
TABLE 5-43
Controls for the Remote Access Rules Dialog Box
Control
Description
Rule Index
(Optional) Assigns a number to a rule. By default, this field displays a number one
greater than the last rule (indicating this rule will be placed bottom of the list). If you
type a lower number, the new rule is inserted into the specified position in the list,
and the rules currently in the configuration are renumbered.
Screen
(Optional) Specifies the Screen for which you want the rule to apply. Type a specific
Screen name in this field if you use centralized management and want a rule to apply
to a specific Screen. The default All applies to all Screens.
Address Object
Specifies from where users may initiate a connection.
User
Lists the user names of SunScreen administrators. Use the names that you defined for
the Administrative User object.
Encryption
Specifies the version of SunScreen SKIP being used to encrypt traffic between the
Screen and the Administration Station.
Certificate Group
Specifies the name of the certificate group, which can correspond to a single certificate
or a certificate group, allowed over this interface.
118
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-43
Controls for the Remote Access Rules Dialog Box (Continued)
Control
Description
Key Algorithm
Identifies the algorithm used to encrypt traffic-encrypting keys. The algorithms
available depend on the strength of encryption (128 bit, or 56 bit) that you are using
with SunScreen.
Data Algorithm
Identifies the algorithm used to encrypt message traffic between the Screen and the
Administration Station. The algorithms available depend on the strength of
encryption (128 bit or 56 bit) that you are using with SunScreen.
MAC Algorithm
Identifies the algorithm used to authenticate traffic.
Tunnel
Identifies the tunnel address used for the communication between the remote
Administration Station and the Screen.
Access Level
Specifies what actions the designated user can perform:
1. ALL – The administrator can display and modify all settings for the Screen.
2. WRITE – The administrator can perform all operations except modifying the
Administration Access rules for any Policy.
3. READ – The administrator can view both the Information and Policy. This level
also allows the user to save and clear logs on the information page. With this
access level users cannot modify any Policy data.
4. STATUS – The administrator can display status information (logs, statistics, status)
but cannot display or modify management settings.
5. NONE – The administrator does not have access.
Description
(Optional) Provides a brief description of the remote administrative access rule.
Move
Enables you to assign a new rule index number for the rule that you highlighted in
the Access Rules for Remote Administration panel of the Administrative Access tab.
Delete
Deletes the access rule that you highlighted in the Access Rules for Remote
Administration panel of the Administrative Access tab.
Help
Displays the online help.
NAT Tab
Use the Network Address Translation (NAT) tab, shown in FIGURE 5-48, to set up
mapping rules to translate IP addresses according to specific rules. These rules
interpret the source and destination of incoming IP packets, then translate either the
apparent source or the intended destination, and send the packets on. You can map
hosts, lists of addresses, ranges of addresses, or specific groups, depending on what
you have configured in your SunScreen installation. See “Address” on page 80 for
information on defining addresses, ranges, or groups of addresses.
Chapter 5
Administration Graphical User Interface
119
FIGURE 5-48
NAT Tab
In general, you map addresses to:
■
Ensure that internal addresses appear as registered addresses on the Internet, or
■
Send traffic for a specific destination to a different, predetermined destination.
Translating both source and destination addresses is not possible—that is, making
packets appear to come from a different IP address and directing the packets to a
different destination simultaneously is not possible.
When defining NAT rules, the first rule (lowest number) that matches a packet is the
one that applies, and no other rules can apply; define specific rules first, then
broader cases later.
FIGURE 5-49 shows the NAT Definition dialog box.
120
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-49
NAT Definition Dialog Box
TABLE 5-44 describes the controls for the NAT Definition dialog box.
TABLE 5-44
Controls for the NAT Dialog Box
Control
Description
Rule Index
Assigns a number to a rule. By default, this field displays a number one greater than
the last rule (indicating this rule will be placed at the end of the list). If you type a
specific number, the new rule is inserted into that position in the list, and the rules
currently in the configuration are renumbered.
Screen
(Optional) Specifies the Screen for which you want the rule to apply. Type a specific
Screen name in this field if you use centralized management and want a rule to apply
to a specific Screen. The default All applies to all Screens.
Mapping
• Static – Specify static mapping to set up a one-to-one relationship between two
addresses. You could use this to set new apparent IP addresses for hosts on your
network without having to reconfigure each host, for example.
• Dynamic – Specify dynamic mapping to map source addresses to other addresses in
a many-to-few relationship. You could use dynamic mapping to ensure that all
traffic leaving the firewall appears to come from a specific address or group of
addresses, or to send traffic intended for several different hosts to the same actual IP
access.
Source
Specify the source address to map from an untranslated packet. Source addresses are
the actual addresses contained in the packet entering the firewall.
Destination
Specify the untranslated destination address for the source packet. Destination
addresses are the actual addresses contained in the packet entering the firewall.
Chapter 5
Administration Graphical User Interface
121
TABLE 5-44
Controls for the NAT Dialog Box
Control
Description
Translated Source
Specify the translated source address for a packet. The translated source is the address
the packet appears to originate from.
Translated
Destination
Specify the translated destination packet address. The translated destination is the
actual address the packet goes to after it leaves the firewall.
Description
Used to provide a description of the mapping defined in this rule.
Add New
Allows adding a new NAT rule.
Edit
Allows you to edit the NAT rule that you highlighted in the NAT tab.
Move
Allows you assign a new rule index number for the rule that you highlighted in the
NAT tab.
Delete
Deletes the access rule that you highlighted in the NAT tab.
Help
Displays the online help.
When defining rules, remember that translating both source and destination
addresses is not possible. Either translate packets so they appear to come from a
different source, or translate packets so they go to a specific destination, but not
both.
All static NAT rules are unidirectional—that is, they work precisely as defined, and
are not interpreted as also applying in the reverse direction. For rules to apply in
both directions, specify two different rules. For example, if you map the source
address internalname.com to the destination publicip.com, you will also have
to map the source publicip.com to the destination internalname.com to
translate traffic in both directions.
VPN Tab
The VPN tab, shown in FIGURE 5-50, allows you to define VPN gateways. Defining
VPN gateways using this mechanism simplifies the creation of VPNs that include
more than two gateways and are managed in a centralized management group.
Note – Each gateway in this type of configuration must be able to connect to the
other ones directly—without going through another gateway.
122
SunScreen 3.1 Reference Manual • May 2000
FIGURE 5-50
VPN Tab
Setting up a VPN requires:
1. Choosing a name for the VPN.
2. Defining the VPN gateway.
3. Adding a rule for the VPN.
Defining VPN Gateways
Use the VPN Definition box, shown in FIGURE 5-51, to define and edit VPN gateways.
Chapter 5
Administration Graphical User Interface
123
FIGURE 5-51
VPN Definition Dialog Box
TABLE 5-45 describes the controls in the VPN Definition dialog box for defining VPN
gateways.
TABLE 5-45
Controls in the VPN Definition Dialog Box
Control
Descriptions
Rule Index
(Optional) Assigns a number to a rule. By default, this field displays a number one
greater than the last rule (indicating this rule will be placed the end of the list). Typing
a lower number inserts the new rule into the specified position in the list and
renumbers the rules currently in the configuration. Rules take effect in order.
Name
Specifies the Name of the VPN to which this gateway belongs. Type the same name in
the Name field for each gateway that is in the VPN.
Address
Specifies the machine to be included in the VPN.
Certificate
Specifies the name of the certificate for this VPN gateway.
Key Algorithm
Specifies the secret (key) algorithm the VPN uses. All gateways in the same VPN must
use the same (key) algorithm.
Data Algorithm
Specifies the data algorithm the VPN uses. All gateways in the same VPN must use the
same data algorithm.
MAC Algorithm
Specifies the MAC algorithm the VPN uses. All gateways in the same VPN must use
the same MAC algorithm.
Tunnel Address
Specifies the destination address on the outer (unencrypted) IP packet to which tunnel
packets are sent.
Description
(Optional) Provides a short description of the VPN gateway.
124
SunScreen 3.1 Reference Manual • May 2000
TABLE 5-45
Controls in the VPN Definition Dialog Box (Continued)
Control
Descriptions
Add New
Allows adding a new VPN rule.
Edit
Allows you to edit the VPN rule that you highlighted in the NAT tab.
Move
Allows assigning a new rule index number for the rule highlighted in the NAT tab.
Delete
Deletes the access rule highlighted in the VPN tab.
Help
Displays the online help.
Adding a VPN Rule
After defining the gateways in a VPN, add a packet-filtering rule for this VPN. Add
the packet-filtering rule using the Packet Filter tab.
When adding a packet-filtering rule for a VPN, leave the Screen field empty.
■
Specify SECURE for the packet-filtering action.
■
Type the name of the VPN in the VPN field.
Note – Use any address in the VPN rules. Only addresses that interact with a VPN
Gateway and the address specified in the rule will apply. The simplest rule uses * for
the source and destination address. This rule allows encrypted use of the specified
service for all addresses in the VPN.
Administration GUI Limitations
The administration graphical user interface (GUI) performs almost all the normal
administration tasks, but it does not support every option of the command line
interface. The command line offers many options for each command. Appendix B
contains information about the command line interface.
Chapter 5
Administration Graphical User Interface
125
126
SunScreen 3.1 Reference Manual • May 2000
CHAPTER
6
Encryption, Tunneling, and Virtual
Private Networks
This chapter contains information on:
■
■
■
Encryption and decryption
How SunScreen uses encryption
Setting up and using a virtual private network
Encryption and Decryption
Encryption is the process by which a readable message is converted to an unreadable
form to prevent unauthorized parties from reading it. Decryption is the process of
converting an encrypted message back to its original (readable) format. The original
message is called the plaintext message. The encrypted message is called the
ciphertext message.
Digital encryption algorithms work by manipulating the content of a plaintext
message mathematically, using an encryption algorithm and a digital key to produce
a ciphertext version of the message. The sender and recipient can communicate
securely if the sender and recipient are the only ones who know the key.
Encryption is important to SunScreen because it provides a mechanism for
protecting the privacy of communications and authenticating the identities of the
sender and receiver. Without encryption, you would have to define packet screen
rules broadly; for example, “all the machines on the Internet” and “all the machines
on the inside.” Encryption technology lets you authenticate machines and users. As
a result, you can define rules that control access by specific cryptographic identities
rather than by general IP addresses.
127
SunScreen uses tSKIP (SunScreen Simple Key-Management for Internet Protocols) as
the basis for its encryption technology. SKIP provides secure, encrypted
communication between a remote Administration Station and the Screen and
between a Screen and a remote SKIP host.
For detailed information on how SKIP encryption works, refer to the SunScreen SKIP
1.5.1 User’s Guide.
Note – SunScreen incorporates cryptography at the network (IP) layer to provide
privacy and authentication over insecure public networks, such as the Internet. See
the SunScreen SKIP 1.5.1 User’s Guide for full descriptions of these and the
Certification Authority (CA) issued keys and certificates.
How SunScreen Uses Encryption
SunScreen uses a combination of public-key and shared-key cryptography to encrypt
and decrypt packets. Any traffic that passes between any two machines or other
SKIP devices can be encrypted. All traffic between a Screen and a remote
Administration Station is encrypted.
Packet Examination
When the rules and policies determine that a specific packet should be encrypted,
the new packet is first checked to see if it is too large to send on. Encrypted packets
can be larger than the original packet for the following reasons:
■
The original packet is encapsulated in a new IP packet for transmission over the
Internet.
■
A SKIP header is added so that the receiver can decrypt the packet.
■
The encryption process requires some padding of the original data.
If the new packet is too large to send on and the original packet carries the “Don’t
Fragment” bit, then a message is sent back to the sender with a request for a smaller
packet (ICMP Fragmentation needed, but Don’t-Fragment bit set). If the new packet
is too large and fragmentation is allowed, the original packet is first fragmented and
then encrypted. The other end of the encryption tunnel can then decrypt each
fragment independently.
The encryption routine builds a new IP packet to carry the original data. It uses the
original source and destination addresses or, if tunneling is specified, the tunnel
source and destination addresses.
128
SunScreen 3.1 Reference Manual • May 2000
After a new packet is created, the original packet is encrypted using the encryption
mechanism (DES, RC2, or RC4) specified and a randomly generated traffic key. The
traffic key is then encrypted using the encryption mechanism (DES or RC2) specified
and a key-encrypting key from the SKIP key manager. The new IP header, SKIP
header, and encrypted data are concatenated to form the new IP packet that is sent
on to the destination addresses.
Note – Because of a limitation in SunScreen SKIP 1.5.1 for Solaris, the RC2
encryption algorithm is not available when running Solaris 7 and Solaris 8 in
64–bit mode.
When an encrypted packet is received, it is passed to the decryptor. By examining
the SKIP header, it determines the correct decryption mechanisms for both the
encrypted traffic key (DES or RC2) and the encrypted data (DES, RC2, or RC4). It
retrieves the traffic-encrypting key from the key manager and decrypts the traffic
key that in turn decrypts the original IP packet.
Finally, the decrypted packet is sent through the rules or policies to determine the
action for the packet (for example, whether the decrypted packet should be passed
or dropped).
Remote Administration
Remote administration from an Administration Station to the Screen installs the
software packages, including SunScreen SKIP, on separate machines, as shown in
FIGURE 6-1. SKIP is required for remote administration because administration
commands travel from the Administration Station to the Screen over a potentially
insecure network.
Internal
Network
Screen
Internet
Administration Station
FIGURE 6-1
External
Network
Administration Station
Remote Administration From an Administration Station to a Screen in
Routing Mode
In FIGURE 6-1, a remote Administration Station on the internal network administers
the Screen located between the internal network and the Internet. This Screen is the
router between the internal network and the Internet. A second remote
Chapter 6
Encryption, Tunneling, and Virtual Private Networks
129
Administration Station for this Screen is located on the external network. Each
Administration Station can be configured to communicate with the Screen using
encryption.
Tunneling
SunScreen uses encryption in a feature called tunneling that is used to hide actual
source and destination addresses. In this feature, you can substitute other addresses
for the addresses on the packet header. When the SunScreen encrypts a packet, it
replaces the packet’s source address with the (optional) tunnel address of the From
Encryptor and replaces the packet’s destination address with the (optional) tunnel
address of the To Encryptor. When the SunScreen decrypts a packet, the original
addresses are restored.
Organizations typically have offices in more than one location. The tunneling feature
provides a way to let the different offices use public networks as a secure private
network without needing dedicated lines and with no changes to user applications.
When a tunnel, or virtual private network (VPN), is set up between two locations, all
data packets traveling from one location to the other are encrypted and encapsulated
inside other packets before they are sent over the public internetwork. Encrypting
the packets guarantees that their contents remain private; anyone capturing packets
to snoop on network traffic between the two locations will be unable to read them.
When the packets arrive at the remote location, they are extracted, decrypted, and
forwarded to their intended destination.
In addition to protecting the privacy of network traffic, tunneling also lets a site
conceal the details of its network topology from intruders or eavesdroppers. Because
the original packets are encrypted, the source and destination addresses in their IP
headers cannot be read. When the encrypted packets are encapsulated in other
packets, the new IP headers identify the addresses of the Screens that protect the
locations, not the hosts that originated the packets. Consequently, the network
topology behind the Screens is never exposed.
FIGURE 6-2 illustrates how tunneling affects the outside IP header of a packet
traveling from Host A to Host B. Note that the encrypted packet containing the
original data Host A sent to Host B is the same whether or not tunneling is used.
130
SunScreen 3.1 Reference Manual • May 2000
Without
Tunnel
Addresses
With
Tunnel
Addresses
Host
A
Source
1.1.1 10
Encrypted Packet
Destination
2.2.2.10
Packet Data
IP Header
Source
Destination
1.1.1.1
2.2.2.1
Source
1.1.1 10
Encrypted Packet
Destination
2.2.2.10
Packet Data
Host
B
Screen
Screen
Internet
1.1.1.10
FIGURE 6-2
IP Header
Source
Destination
1.1.1.10
2.2.2.10
1.1.1.2
1.1.1.1
2.2.2.1
2.2.2.2
2.2.2.10
Effect of Tunneling on Contents of IP Headers
If you do not use a VPN (a tunnel) to transfer data between the two locations, the
source and destination addresses on the outer IP header are the same as the source
and destination addresses on the inner (encrypted) IP header: 1.1.1.10 and 2.2.2.10,
respectively. Someone intercepting this packet cannnot to read its contents, but can
determine that hosts with IP addresses 1.1.1.10 and 2.2.2.10 reside behind the
Screens protecting the two locations.
If you use a VPN to transfer data between the two locations, the Screen protecting
Host A substitutes the IP address of its external interface (1.1.1.1) for the IP address
of host A (1.1.1.10) in the Source Address field of the external IP header. Similarly, it
substitutes the external IP address of the Screen at the other end of the tunnel
(2.2.2.1) for the IP address of Host B in the Destination field. The local Screen then
sends the packet through the nonsecure public network to the remote Screen.
When the remote Screen receives the packet, it strips off the encapsulation and
decrypts the original packet from Host A. The remote Screen then reads the
destination address from the original IP header of the decrypted packet and
forwards the packet to Host B.
Because the IP addresses behind the Screen are never exposed to hosts on the
external Internet, the two locations do not need to assign externally valid IP
addresses to hosts behind the Screens. As long as hosts behind the Screens do not
need to communicate with hosts on the Internet, the two locations can use a shared
IP address space, as shown in FIGURE 6-3.
Chapter 6
Encryption, Tunneling, and Virtual Private Networks
131
Network
192.1.2.xxx
Network
192.1.2.xxx
Internet
Screen
FIGURE 6-3
Screen
Geographically Dispersed Network
Defining a VPN
A VPN is a group of Screens that transfer encrypted data among themselves. A VPN
simulates a private network using a public network, with IP level encryption
providing privacy.
After a VPN has been defined, you can refer to this VPN when adding rules to your
security policy. VPNs make it possible for you to define your security policy with
fewer rules. The system automatically generates the multiple rules that the VPN
defines.
In defining a VPN:
■
Choose a name for the VPN. This name is used in the Name field in the VPN
gateway entries. It is also used in any policy rules that refer to this VPN.
■
Define a VPN gateway object for each Screen in a VPN. You define VPN gateway
objects in the administration GUI using the VPN Definition dialog box that is
accessible from the VPN tab in the Policy Rules. page
When defining a VPN gateway object, specify the following information:
132
■
Rule Index – (Optional) Assigns a number to the VPN gateway entry. This affects
the position within the VPN gateway list. By default, the GUI will place new
entries at the end of the current list. Remember that SunScreen uses ordered rules,
so be sure to place the rule in the order in which you want it to take effect.
■
Name – This is the name of the VPN to which this VPN gateway is a member.
Use the name you chose for the VPN.
■
Address – Specify the addresses protected by this Screen. Generally, this address
will be the same as one of the interface addresses for this Screen.
SunScreen 3.1 Reference Manual • May 2000
Note – You can use any address in the VPN rules. Only addresses that interact with
a VPN gateway and the address specified in the rule will apply. The simplest rule
uses * for the source and destination address. This rule allows encrypted use of the
specified service for all addresses in the VPN.
■
Certificate – Specify the certificate used for this Screen when encrypting packets
to other Screens in the VPN. For a particular VPN, all certificates must refer to
keys of the same strength (for example, 512–, 1024–, 2048–, or 4096–bit
Diffie-Hellman keys).
■
Key Algorithm – Specify the key algorithm that is used when encrypting packets
to other Screens in the VPN. This field must be identical in all VPN gateway
entries with the same VPN name.
■
Data Algorithm – Specifies the data algorithm that is used when encrypting
packets to other Screens in the VPN. This field must be identical in all VPN
gateway entries with the same VPN name.
■
MAC Algorithm – Specifies the MAC algorithm that is used when encrypting
packets to other Screens in the VPN. This field must be identical in all VPN
gateway entries with the same VPN name.
■
Tunnel Address – Specifies the Screen’s tunnel address that is used when
encrypting packets to other Screens in the VPN.
■
Description – Optionally, specify a short description of this VPN gateway entry.
Consider a site, similar to that shown in FIGURE 6-4, that has ten Screens. One of the
systems protected by each Screen is a mail server. Assume that your security policy
allows the exchange of encrypted mail between all these mail servers and you want
to define rules to allow SMTP between all of the mail servers.
Chapter 6
Encryption, Tunneling, and Virtual Private Networks
133
Network2*
Network3*
Network4*
Screen2
Screen3
Screen4
Network1*
Screen1
Network5*
Screen5
Internet
Screen6
Screen10
Network10*
Screen9
Network9*
Screen8
Screen7
Network8*
Network7*
Network6*
* Each network contains a mail server, named MailServer1 through 10 respectively.
FIGURE 6-4
A Site of Ten Networks, Each with a Mail Server, Protected by Ten Screens
Without a VPN, you must define nine rules for each mail server to send mail
encrypted to the other nine mail servers. Because you have ten mail servers, you
must define a total of 90 rules. If, instead you defined a VPN, you only need a single
rule: one that allows the mail servers to send mail to the other mail servers using the
VPN. Because you have ten Screens in the VPN, you must define ten VPN gateway
entries.
Looking at this example in detail, FIGURE 6-4 shows the configuration. The Screens
are labeled Screen1 through Screen10. The mail servers behind them are labeled
mail1 through mail10 and are part of network1 through network10.
The first step is defining the VPN itself. Choose a name for the VPN. In this example,
that name is “ourVPN.” Next, for each Screen that is a member of that VPN, define
a VPN gateway object. For each VPN gateway object, specify the VPN name
(ourVPN), the addresses of the systems that the Screen protects, the Screen’s
certificate, the tunnel address, and the encryption parameters that will be used for
the VPN. All VPN gateway objects in a particular VPN must have identical
encryption parameters, and the certificates must refer to keys of the same strength
(512–, 1024–, 1124–, 1280–,2048–, 2176–, 3072–, or 4096–bit Diffie-Hellman keys).
Once you have defined the VPN objects, as as shown in FIGURE 6-5, you can use the
VPN in any rule. Select SECURE as the action for the data between the sender and
the SMTP server, and specify the name of the VPN.
134
SunScreen 3.1 Reference Manual • May 2000
FIGURE 6-5
Policy Rules Panel Showing the VPN Tab with VPN Entries
Adding a VPN Rule
Assuming an address group MailServers containing all the mail servers
exchanging encrypted mail, define the rule in the Rule Definition dialog box shown
in FIGURE 6-6.
FIGURE 6-6
Completed Rule Definition Dialog Box for the VPN Rule
Chapter 6
Encryption, Tunneling, and Virtual Private Networks
135
The VPN rule appears on the Packet Filtering tab of the Policy Rules page. The more
restrictive a rule is, the earlier it should be ordered in the list of rules because the
rules take effect in order. The more restrictive VPN rule comes before the more
general rule and so will take effect earlier.
FIGURE 6-7
VPN Rule
There is no limit to the number of VPNs to which a Screen can belong. For example,
you can to define two VPNs—one for encryption at 1024 bits, and one for encryption
at 4096 bits. A single Screen can belong to both of those VPNs: one entry specifying
the 1024–bit certificate, and the other specifying the 4096–bit certificate.
VPN Limitations
Currently, the VPN object has the following limitations:
136
■
All certificates on the gateways of a particular VPN must be of the same strength.
If you want to have different encryption strengths in your configuration, you
must define multiple VPNs, one for each strength.
■
The key, data, and MAC algorithms must be the same for all gateways within a
VPN.
SunScreen 3.1 Reference Manual • May 2000
CHAPTER
7
Network Address Translation
This chapter contains information on:
■
■
■
NAT rules
Static and dynamic NAT
Examples of NAT
Network Address Translation (NAT)
The network address translation (NAT) feature enables a Screen to translate an
internal network address to a different network address. As it passes packets
between an internal host and a public network, the addresses in the packet are
replaced with new addresses transparently, checksums and sequence numbers are
corrected, and the state of the address translation is monitored. You specify when a
packet using ordered NAT is applied based on source and destination addresses.
SunScreen NAT gives you fine-grain control by adding ordered NAT translations,
allowing table entries to intersect, and allowing you to specify when to have NAT
translate the source or destination addresses.
NAT enables a Screen to translate an internal network address to a different network
address. As it passes packets between an internal host and a public network, the
addresses in the packet are replaced with new addresses transparently, checksums
and sequence numbers are corrected in both the IP header and the TCP or UDP
header, and the state of the address translation is monitored. You specify when a
packet using ordered NAT translations is applied based on source and destination
addresses.
137
Note – Be sure to configure your NAT rules so they do not perform address
translation while an internal host is attempting to communicate directly with the
Screen.
Additionally, services such as FTP also carry IP address information. These packets
must also be changed, ensuring that the checksums and sequence numbers are
correct. All of this is done inside the Screen’s kernel to ensure high-speed processing
and transparency to the end user and applications. NAT is stateful, which increases
the efficiency of lookups in the address translation table by using address hashings
and checksum adjustments that use differential checksum calculations.
NAT is typically used in the following situations when:
■
It is not feasible to renumber all the hosts in your network.
■
The current private network uses a set of unregistered (private) IP addresses
owing to a lack of available public addresses, or to simplify renumbering hosts
should you change ISPs.
■
You have a very large network to connect, but your ISP allotted you a limited
range of IP addresses.
■
You want to hide the addresses on the current private network from the outside
world.
Note – Using NAT to hide addresses differs from tunneling in that NAT does not
rely on the use of encryption and decryption and, consequently, does not require an
encryption-decryption device at each end of the connection over the public network.
NAT lets you use unregistered Internet addresses to number your internal networks
and hosts and still maintain full connectivity to the Internet. The Internet Assigned
Numbers Authority (IANA) has reserved the following three blocks of the IP
address space for private internets:
■
10.0.0.0–10.255.255.255 (Class A address range, which supports about 16 million
addresses)
■
172.16.0.0–172.31.255.255 (Class B address range, which supports about 65,000
address)
■
192.168.0.0–192.168.255.255 (Class C address range, which supports 254
addresses)
With this approach, you can use a registered (public) Class C address space, which
offers about 254 externally routable addresses, to provide connectivity for an
unregistered Class B network, which supports approximately 65,000 hosts or 255
networks of 254 hosts (internally).
138
SunScreen 3.1 Reference Manual • May 2000
NAT Rules
There are two types of NAT rules: (1) static and (2) dynamic. Static NAT rules
provide a one-to-one translation of addresses. Dynamic NAT rules provide an N-toM, typically many to one, translation of addresses.
NAT rules are specified by their type (STATIC or DYNAMIC), their source and
translated source address, and their destination and translated destination address.
Addresses in NAT rules use the same set of address objects used in other rules.
NAT rules are ordered. The first NAT rule that matches a packet takes effect, and no
other NAT rules apply. Therefore, place specific NAT rules first, broader NAT rules
later.
Valid translations are:
■
Source and Translated Source are the same, and Destination and Translated
Destination are the same (no translation will occur).
You cannot translate both the source and destination addresses in any single
packet with either a single translation or in a combination of translations. A
nontranslating NAT rule may be placed ahead of more general NAT rules, to
override part of the later, more general NAT rule.
■
Source and Translated Source are the same, and Destination and Translated
Destination are different.
■
Source and Translated Source are different, and Destination and Translated
Destination are the same.
Static NAT
Registered addresses are necessary for advertised kinds of resources, such as publicly
accessible servers on your network, because these machines must be at well-known,
fixed addresses. Static NAT is frequently used to provide public access to HTTP or
FTP servers that use private addresses. These servers must use static NAT reverse
rules so that other hosts can use the same registered addresses to reach them, so the
reverse rules must be generated by you.
Chapter 7
Network Address Translation
139
One-to-One Translations
Use static NAT rules to make one-to-one translations between either single pair or
multiple pairs of addresses. Most commonly, static NAT rules are used to translate
an advertised address for a public server to a different address.
A static NAT rule translates either the source or destination addresses in a packet.
In most cases, this means that you will need to define two NAT rules:
1. One to translate the source address when the packet is flowing in one direction.
2. A second rule to translate the destination address when packets are flowing in the
other direction.
■
Example of Static NAT Rules in One-to-One Translation
Assume that your public web server has an address of 10.0.0.1 (defined by the
address object "private_www") and you want to allow access to this web server
through the public address 199.190.177.1 (defined by the address object
"public_www"). Assume also that the address Internet represented the Internet
addresses.
To do this requires two static NAT rules, as shown in TABLE 7-1:
1. The first rule specifies that the destination address public_www (199.190.177.1) is
the translated destination address private_www (10.0.0.1). This NAT rule
handles packets flowing to the web server.
2. The second rule specifies that the source address private_www (10.0.0.1) is the
translated source address public_www (199.190.177.1). This NAT rule handles
packets flowing from the web server.
TABLE 7-1
Type of NAT
Rule
Source
STATIC
"Internet"
STATIC
"private_www"
Static NAT Rules
Translated
Source
Translated
Destination
Comment
"public_www"
"Internet"
"private_www"
Packets to server
"Internet"
"public_www"
Destination
"Internet"
Packets from server
Note – The order of the addresses is reversed in the two rules.
Address Range to Another Address Range
You also can use Static translations to translate a range of unregistered addresses to
a range of registered addresses. Each range of addresses must contain the same
number of addresses.
140
SunScreen 3.1 Reference Manual • May 2000
■
Example of Static NAT Rule with a Range of Addresses
You can translate the address range containing 199.190.177.1 through 199.190.177.100
to an address range containing 10.0.0.1 through 10.0.0.100 since both ranges contain
100 addresses. In this example, 199.190.177.1 translates to 10.0.0.1, 199.190.177.2
translates to 10.0.0.2, ending with 199.190.177.100 translating to 10.0.0.100.
Dynamic NAT
Use dynamic NAT to translate a set of unregistered IP addresses to a smaller set of
registered addresses. Dynamic NAT allows connecting a large number of hosts to the
public Internet using a limited number of registered addresses.
Unlike static NAT, which sets up a one-to-one translation between internal
unregistered addresses and external registered addresses, dynamic NAT creates a
many-to-one translation where several internal addresses use the same public
address. Dynamic NAT avoids IP address conflicts by maintaining a state table that
records five values (source address, source port, destination address, destination
port, and protocol) for each TCP or UDP connection. A Screen can multiplex
thousands of translations over a single registered address.
Dynamic NAT is unidirectional, meaning that communication can be initiated only
internally from the unregistered private network. Dynamic NAT only works when a
user originates a connection from inside the firewall; packets from outside that are
not in the address lookup table of an established connection cannot identify a host
on the private network and are discarded.
Dynamic NAT only works for connections initiated from the Source address systems.
These generally represent machines with unregistered addresses that you want to
translate to registered address.
■
Example:
Assume you have workstations with unregistered addresses defined by the address
group my_private that you want to allow access to the Internet using a set of
public addresses defined by the address group my_public. The address Internet
represents the addresses of the internet.
Chapter 7
Network Address Translation
141
To do this, define a dynamic NAT rule, as shown in TABLE 7-2, that specifies that the
Source address my_private becomes the translated source address group
my_public. Destination and translated destination are the address Internet,
which limits the scope of the translation of packets going to or from the Internet.
TABLE 7-2
A Dynamic NAT Rule
Type
Source
Destination
DYNAMIC
my_private
Internet
Translated Source
my_public
Translated
Destination
Comment
Internet
Dynamic NAT Collisions
Because dynamic NAT translates a large set of addresses into a smaller set of
addresses, the addresses could be translated to the same address, in which case the
translations are said to collide.
Address collisions occur if the Screen cannot translate the address uniquely. An
address collision causes the connection to cease. Address collisions occur if all the
following conditions are met:
■
Two systems using NAT must connect to the same destination service (the same
remote address and the same remote port number using the same protocol).
For example, this condition is met if two systems using NAT establish a web
connection to www.sun.com.
■
The two systems must choose the same local port number to make the connection.
Because most systems select from a set of at least 32 000 different local port
numbers, the chance of this happening is usually small. If, however, multiple
systems boot at the same time (such as after a power failure), this condition can
be met more frequently because of likelihood of systems with the same operating
systems assigning local port numbers starting at the same number. This is a
transient condition because different events between the two systems will likely
cause the local port number selection to differ over time.
■
142
The NAT code must choose to translate the two connections using the same
translated address.
SunScreen 3.1 Reference Manual • May 2000
Expressed as a probability, the chance of this happening for two systems is equal to
1/M where M is the number of addresses in the Translated Source field. For
example, if the Translated Source field contains an address object that represents 10
addresses, the probability of NAT choosing the same translated source address for
two systems would be 1/10 or 10 %.
The probability of a collision is:
Probability of two
systems connecting to
the same remote
service
X
Probability of two
systems choosing the
same local port
X
1
___________________
number of addresses in
Translated Destination
Translation collisions cause service to be denied to a network user. Translation
collisions occur when network software cannot complete the address translation
process because two or more packets are not uniquely identified. Each packet must
have a destination IP address, a destination port, source IP address, a source port,
and protocol if it is to be delivered. These elements are processed as a 5-tuple of
information of the form: (desaddr, dest port, srcaddr, src port, proto), which
is part of the packet header.
A 5–tuple is unique as long as at least one of the five pieces of data that it contains
differs from the others with which it is being compared. Since each piece of data has
a large number of possible values, the number of possible permutations for the
5–tuple is enormous. Therefore—an unlikely scenario—for a translation collision to
occur, multiple internal machines using the same registered IP address must try to
gain access to the same registered address at the same destination port number and
from the same source port number, all at the same time.
Suppose a user at the unregistered address U5, shown in FIGURE 7-1, attempts to go
to a web page at the registered destination address 192.4.15.37 at destination port 80
from source port 34080 through the registered address R5. Another user at U6 can do
the same to the same address and destination port through source port 34070, or go
to a different web page through source port 34080.
Chapter 7
Network Address Translation
143
TABLE 7-3 shows the translation of unregistered addresses, Un, to registered
addresses, Rn.
TABLE 7-3
Two Dynamic Addresses
Registered IP
Address
Destination IP
Address
Destination Port
Source Port
Protocol
R4
192.4.15.37
80
34080 (on U5)
tcp
R4
192.4.15.37
80
34070 (on U6)
tcp
R4
192.4.15.44
80
34080 (on U7)
tcp
If a user at unregistered address U7 attempts to go to a web page at the registered
destination IP address 192.4.15.44 at destination port 80 from source port 34080
using registered address R4, a translation collision will occur. The user at U7 would
have to use another source port to have a unique 5-tuple and avoid a translation
collision, which would happen automatically during a subsequent attempt to
connect.
Situations such as power failures typically result in translation collisions. When
power is restored, all hosts on a network come up at the same time and try to
reestablish network connections. Each host’s operating system resets its source port
counter to a low number. It may take time for the counters on each machine to cycle
up to higher and more randomized port numbers (which are more likely to produce
unique 5-tuples). In the interim, translation collisions may cause network service to
be denied temporarily. Internal hosts must continue trying to establish network
connections until the NAT rules resolve the translation collisions.
Note – Ports 0 through 1024 are reserved for well-known port assignments and are
controlled by the IANA. To avoid conflicts, the Solaris operating environment uses
ports that range approximately from 32768 through 65535. Different
implementations of TCP/IP in various operating environments have different rules
and limits for their optional (ephmeral) port choices.
Choosing NAT Addresses
In all NAT situations, one of the addresses in a NAT translation is virtual. It does not
really exist and must be simulated by the Screen and other systems in the network.
The virtual address is:
■
144
If Source and Translated Source addresses are different, then Translated Source
address is virtual.
SunScreen 3.1 Reference Manual • May 2000
■
If Destination and Translated Destination addresses are different, the
"Destination" address is virtual.
Because virtual addresses do not physically exist, how these address are selected
and who simulates them is restricted. Simulating a virtual address means providing
the functions of APRing and routing.
In routing mode (not needed in stealth mode), the Screen must respond to APR
requests for the public addresses (R2 through R8) because it will be translating
public addresses to private addresses. Add an arp entry (using the command
arp -s IP_address ether_address pub) for them. Either add this entry each time that
you reboot the Screen or add it to a startup script that runs at boot time. If you are
administering the Screen in routing mode remotely, either go to the Screen to add
this entry, or have a rule in your policy that allows logging in (rlogin) to the Screen
remotely.
In stealth mode, the Screen automatically responds to the APR requests from public
address.
NAT Examples
The following NAT examples show how to set up NAT when using only one
registered IP address, and shows two scenarios that illustrate how a demilitarized
zone could use registered addresses or unregistered addresses with NAT.
Example One
If you only have one registered IP address (A) and you want to have all inbound
traffic to A, go to your Screen and have all other hosts use that address (A) for
unidirectional, outbound traffic, then set up NAT as shown in TABLE 7-4.
TABLE 7-4
Example of a One-Address NAT Table Entry
TYPE
Source
Destination
Translated
Source
Translated
Destination
1
STATIC
*
A
*
A
2
DYNAMIC
Inside
Internet
A
Internet
Index
Screen
Comment
where Internet is all addresses on inbound interface A; and Inside is all internal
hosts on all other interfaces. With only these NAT rules, all hosts in the Inside
communicate with their private, unregistered, addresses when communicating with
the Screen or among themselves.
Chapter 7
Network Address Translation
145
Write your filtering rules in the context of the internal addresses.
Example Two
Registered addresses are necessary for advertised kinds of resources, such as publicly
accessible servers on your network, consequently these machines must be at wellknown, fixed addresses. Because a host must have a registered address before it can
communicate over public networks, either machines that host public resources must
have stable registered addresses, or their unregistered (internal) addresses must
translate to stable registered addresses. The following scenarios illustrate how a
demilitarized zone (DMZ), an internal network with limited public access, could use
registered addresses or unregistered addresses with network address translation.
Scenario 1: DMZ Uses Registered Addresses
In FIGURE 7-1, the Screen, in routing-mode, uses Q1 as its own IP address on the
external network interface. It has a DMZ network with registered addresses R1
through R8 on a second interface. The Screen (Q1) and the servers in the DMZ (the
FTP server (R2) and the WWW server (R3)) have routable registered addresses on
the public network that allow them to communicate with any other machine with a
registered address. The Screen uses the remaining registered addresses (R4 through
R8) for NAT.
Outside
Registered (Rn) Addresses
Internet
Registered
Network 1
Inside
Unregistered (Un) Addresses
U2
U1
Q1
R1
Registered
Network 2
FTP
R2
U3
U4
Un
WWW
R3
DMZ Registered (R1–R8) Addresses
FIGURE 7-1
146
Scenario 1: Static and Dynamic NAT
SunScreen 3.1 Reference Manual • May 2000
The Screen uses dynamic NAT to translate the addresses in its unregistered address
range (U2–Un) to translate the remaining addresses in its registered address range
(R4–R8). When an internal host with an unregistered address tries to connect to an
external host with a registered address, the Screen assigns the internal host a
registered address to use for the duration of the network communication session.
Scenario 2: DMZ Uses NAT Addresses
FIGURE 7-2 illustrates an organization that has a network consisting of a large number
of unregistered addresses (Un) and a set of eight registered addresses (R1–R8). Hosts
on the inside network must be able to communicate through the Screen with
external hosts.
Outside
Registered (Rn) Addresses
Inside
Unregistered (Un) Addresses
U5
U6
U4
Internet
R1
U1
U7
FTP
U2
(R2)
WWW
U3
(R3)
Un
DMZ Unregistered Addresses
FIGURE 7-2
Scenario 2: Static and Dynamic NAT
In FIGURE 7-2, the Screen is connected to the public network R1-R8. R1 is its IP
address on the public network interface. It uses static NAT to translate the
unregistered DMZ addresses of the FTP server (U2) and the WWW server (U3) to the
registered (public) addresses R2 and R3. The private addresses U4 through Un will
be translated dynamically to the registered addresses R4 through R8. Because the IP
addresses of the servers and the internal network are translated to routable
registered addresses, they can communicate with any other registered address.
The Screen uses dynamic NAT to translate the addresses in its unregistered address
range (U4–Un) to the remaining addresses in its registered address range (R4–R8).
When an internal host with an unregistered address tries to connect to an external
host with a registered address, the Screen assigns the internal host a registered
address to use for the duration of the network communication session.
Chapter 7
Network Address Translation
147
This scenario has the advantage that if you change ISPs, you do not have to
readdress all the hosts on your internal registered network.
Routing Interface Examples
For routing interfaces, you can select the registered address as the address of one of
the Screen’s interfaces. In this case, the Screen simulates the registered address. The
limitation here is that you only have a single address. Also selecting the interface
address as the registered address for a static NAT rule can limit your ability to
connect to the Screen itself. Because you are not adding additional networks, no
routing changes are required.
For example, consider a Screen with routing interfaces. One of the network
interfaces has the address 199.190.177.1. You can use this address as your registered
address in NAT rules.
For routing interfaces, you can select the unused addresses on one of the networks to
which the Screen is directly connected as virtual addresses. In this case, it is
necessary so that it can respond to APR requests for these virtual addresses.
For routing interfaces, you can select the virtual addresses from a network not
directly connected to the SunScreen. In this case, you must make sure that the
correct routing information is propagated so that packets destined for these
addresses pass through the SunScreen. If you define new networks (especially ones
in which all the addresses on the network are virtual), you may need to add static
routing entries on some routers to simulate these networks.
Stealth Interface Examples
For stealth interfaces, you can select the registered addresses from the list of unused
addresses on the network that the Screen segments. In this case, Screen simulates the
virtual addresses and responds to APR requests for those addresses. Since you are
not adding additional networks, no routing changes are required.
For example, consider a SunScreen with stealth interfaces that segments the network
199.190.177.0 (netmask 255.255.255.0). In this example, the addresses 199.190.177.100
through 199.190.177.254 are unused and can be used as virtual addresses in network
address translations.
For stealth interfaces, you can select the registered addresses from a new virtual
network you create. For this to work successfully, you must be able to assign
multiple addresses on multiple networks on the routers you use.
148
SunScreen 3.1 Reference Manual • May 2000
Applying NAT
NAT translations for your site are automatically applied to all packets. When
packets addressed to an internal host are received from an external host, the Screen
translates network address information in the packets before they are processed by
the stateful packet-filtering engine. Similarly, packets travelling from an internal host
to an external host are filtered before NAT takes place. This approach lets you use
your internal addresses when you define filtering rules, simplifying policy
management.
Chapter 7
Network Address Translation
149
150
SunScreen 3.1 Reference Manual • May 2000
CHAPTER
8
High Availability
This chapter describes high availability (HA). It contains information on:
■
■
■
Developing a high-availability (HA) policy
How HA works
Configuring HA
High Availability (HA)
High Availability (HA) allows you to deploy groups of Screens together in situations
where the connection between a protected inside network and a nonsecure outside
network is critical. At any time, one member of the HA cluster is the active Screen. It
performs packet filtering, network address translation, logging, and encryption or
decryption of packets travelling between the inside and outside networks. The other
members of the HA cluster, the passive Screens, receive the same packets and
perform the same calculations as the active Screen, and mirror the state of the active
Screen, but they do not forward traffic.
HA Policy
When you set up an HA cluster, you designate one Screen as its primary HA Screen.
It is configured with the policy’s configuration objects, including named screen
objects, like address or services with attributes that include these settings, and policy
rules that the HA cluster will use. When you activate a policy, the policy’s rules are
copied from the primary HA Screen to the secondary Screens in the HA cluster.
Solaris settings, such as network interfaces and routing configuration, are not copied
from the primary Screen and must be identical on all the Screens in the HA cluster.
151
Caution – Because the HA cluster transmits secret keys and policies in the clear
over the dedicated HA network, keep the HA network physically secure.
‘The
IP addresses of the HA interfaces for each member of the HA cluster on the for
dedicated network connections must be unique. Assign all HA Screens the same IP
addresses on their filtering interfaces. FIGURE 8-1 shows a network protected by two
Screens in an HA cluster. Each Screen in the HA cluster connects to the external and
internal networks through Ethernet hubs, which pass the same signals to all
members of the HA cluster at the same time. Each HA Screen, therefore, sees the
same traffic, ensuring that passive Screens can duplicate the state of the packet filter
engine should the active Screen fail.
172.16.2.1
Active HA
Screen
172.16.3.1
172.16.4.1
Internal
Network
Hub
Dedicated
network
connection Hub
between
HA
Screens
Internet
172.16.4.2
172.16.2.1
FIGURE 8-1
172.16.3.1
Passive
HA Screen
Network With HA Cluster of Screens
HA Network Connections and Failovers
Once the HA cluster is running, the active and passive Screens poll each other every
few seconds to verify connectivity and status. If the active Screen fails or becomes
unavailable, the passive Screen that has been running the longest takes over as the
active Screen within 15 seconds. During this time (before the passive Screen takes
over), no traffic will go through the HA cluster.
HA is designed to maintain the great majority of network connections. In the case of
a reboot (an orderly shutdown), the active Screen being rebooted notifies the passive
Screens, and the appropriate passive Screen takes over as the active Screen without
152
SunScreen 3.1 Reference Manual • May 2000
loss of connections. Because the passive Screens do not forward, reject, or log
packets, the load on passive Screens is less than the load on the active Screen.
Consequently, load-induced faults that affect the active Screen are unlikely to affect
the passive Screens.
Failover can disrupt these connections:
■
Continued connections, for protocols that keep state (memory), such as TCP
connections.
■
Stateful connections, such as FTP, NFS, NIS, and RPC.
These connections can be lost under any of the following conditions:
■
The Screen taking over filtering does not have all the same state information
when the failover condition occurs.
■
Rarely, a connection through the HA cluster uses dynamic NAT and two or more
connections have identical destination addresses, destination ports, or source
ports.
HA automatically disconnects if it is only running on one machine, allowing it to act
like a standard Screen.
You can configure Screen as part of an HA cluster during installation. Alternatively,
you can configure HA settings through the command line, as described in
Appendix B, “Command Line Reference.”
Configuring HA
High Availability has the following limitations:
■
HA does not work on machines running the Solaris 7operating environment for
the Intel Platform.
■
Screens in an HA cluster do not exchange state information, they accumulate state
independently by processing the same packets. For optimal performance,
whenever possible, an HA cluster should comprise systems of equal size (same
CPU speed, and memory size). A slower Screen in passive mode can fall behind
in processing and eventually fail to have the same state as the active Screen.
■
To reinstate a repaired Screen, install it as a secondary Screen and add it to the
cluster.
You do not have to switch back to the original Screen except when its abilities or
speeds are better. If they are, you can force the faster machine to take over as the
active Screen, or wait until both machines have the same state (eventually the out-ofsync connections will time-out and become synchronized) and force the failover.
Chapter 8
High Availability
153
■
Secrets are sent in the clear on the dedicated HA network to facilitate
administrative communication within the HA cluster. Reserving the HA interface
as a separate network from other traffic helps prevent discovery of the Screen’s
private certificates.
■
Each Screen in an HA cluster must have a unique node name and a unique IP
address on the dedicated HA network. All other aspects of the Solaris system
configurations must be identical on all Screens in the HA cluster. This includes
the configuration of all network interfaces (other than the HA interface).
■
HA does not work well with proxies because proxy state tables are not present on
all HA machines.
■
HA Screens must be connected to each other through a shared network (such as a
10BaseT or 100BaseT hub) and not through a switched network (such as an
Ethernet switch) because it will send each packet to only one HA Screen, rather
than to all of them.
■
HA cannot be used on networks that use media other than Ethernet, such as
FDDI, Token-Ring, or ATM.
■
Because passive HA hosts do not generate traffic (other than automatic
administrative traffic, such as HA administration and HA heartbeat), you cannot
use telnet for connecting to passive HA Screens. You can use telnet for
communicating with an active HA Screen only.
■
The HA cluster decides internally which member will be the active Screen.
Administering HA
If the HA cluster has an ADMIN interface, you can use the IP address of the ADMIN
interface to administer the Screen. The ADMIN interface must be on the primary
Screen.This is the normal setup for stealth mode and is the best way to set up
routing mode as well.
If the HA cluster does not have an ADMIN interface, the Administration Station
needs to connect to a unique IP address to determine which Screen is the primary
and which is the secondary. The filtering interfaces share the same IP address in
routing mode or have no IP address in stealth mode. The only interface with a
unique IP address is the HA interface. You must connect to the HA interface of the
primary Screen for administration.
The configuration information is only stored on the primary Screen. If, therefore,
with remote administration, you want to change the configuration, you must
connect to the primary Screen using an ADMIN interface or the HA interface. The
primary does not have to be the active Screen. A passive Screen still receives and
transmits administration traffic.
154
SunScreen 3.1 Reference Manual • May 2000
If the address for HA interfaces on the dedicated network connecting the HA
Screens are unregistered, you can still administer the primary Screen. The
Administration Station has a route to the HA interface of the primary Screen because
the HA cluster and the Administration Station are both connected to the network for
which the Screens are filtering traffic and can, therefore, communicate with each
other. Problems occur when the Administration Station cannot connect directly to
one of the Screen’s filtering interfaces and the packets from the Administration
Station must be routed to the Screen. In this case the routers in between must also
know about the unregistered HA interfaces.
Chapter 8
High Availability
155
156
SunScreen 3.1 Reference Manual • May 2000
CHAPTER
9
Authentication
This chapter discusses the following topics:
■
■
■
■
■
■
User authentication
Authorized user
Administrative user
Proxy user
Details of RADIUS user authentication
SecurID Authentication
User Authentication
SunScreen provides the ability to configure user entities. These entities are used to
authenticate individual administrators of Screens and to allow access through the
Screen when using proxied services.
Authentication enables you to verify the identity of both internal and external users
based on user name and a simple text password, or on a user name and SecurID
token passcode, or both.
Proxies provide a means to validate, regulate, and extend the abilities of certain
services beyond those afforded by kernel-based stateful packet filtering. (See
Chapter 10, “Proxies”.)
157
User Identification
SunScreen contains two aspects of user identification: authorized user (as defined in
the authuser database) and proxy user (as defined in the proxyuser database). In
addition, there is an alias, administrative users, for authorized users. Administrative
users are functionally identical to authorized users and their role is defined by the
access rules.
Save Is Not Required With Certain Common
Objects
The common objects authorized user, administrative user, and proxy user that
appear in the administration GUI are automatically saved when they are edited or
new objects are added. You do not need to save these objects. Once these objects are
added or edited, the change applies immediately and cannot be reversed. The Save
button in the administration GUI is greyed out to show that it is inactive.
Note – Although the changes made to these objects are saved immediately, they do
not take effect until a policy is activated. The administration GUI edits authorized
users, which are authuser objects; administrative users, which are adminuser
objects; or proxy users, which are proxyuser objects.
From the command line, you do not need to type save before quit if only
authuser, adminuser, proxyuser, logmacro, or vars entities have been altered.
If you attempt to save without changing entities other than authuser, proxyuser,
logmacro, or vars, you are reminded by a non-fatal message and you can simply
quit the configuration editor.
Once changes have been made to these objects, the system configuration must be
activated to install the new objects and to propagate these changes to secondary
Screens.
Authorized Users
Authorized user is a named common object that describes an individual user who is
distinct from all others. The attributes provide a repository for demographic and
authentication data about that individual.
158
SunScreen 3.1 Reference Manual • May 2000
Access to and use of the administrative GUI functions require that you establish the
authorized user identity before administration is allowed. Both the administration
GUI Login screen and the login subcommand of the ssadm command line
reference an authorized user object.
Authorized user objects contain information sufficient to allow authentication of
users of SunScreen. Validation information can either be: (1) simple-text password or
(2) SecurID token PASSCODE; users can also be configured to have both means of
authentication.
The authenticity of an authorized user only establishes the identities of individual
administrators, not the various roles they may play while using SunScreen. Role is
established in one of two ways: (1) reference within the User field in the
administrative access rules of a policy, or (2) reference from a packet filtering rule
that uses user authentication (proxies).
Defining an Authorized User Object
Note – In examples, the names of authorized users, proxy users, and other user
naming items are often deliberately chosen to be different for purposes of clarity and
illustration.
The authorized user and proxy user objects can be created and managed by both the
administration GUI and the command line interface. The administration GUI pages
that manipulate these objects have already been elaborated in the administration
GUI chapter. This section describes the attributes of these objects and their
manipulation using the command line.
The authorized user object contains the following items:
■
name name of the entity (1 to 255 characters)
■
enable | disable – the flag for the entire object. If disabled, authentication
of the associated user is always denied. The default is enabled.
■
password={ pwitem } – (optional) a simple-text password for this user.
■
securid={ siditem } – (optional) a SecurID mapping for this user.
■
real_name="rnstr" – (optional) a demographic string that can be used to
identify the person in a more readable form.
■
contact_info="cistr" – (optional) a demographic string that can be used to
automate contact with the person (for example, electronic mailbox address).
■
description="descstr" – (optional) a demographic string that can be used to
store other notations about the person.
Chapter 9
Authentication
159
Note – Either a password or securid item or both must be present for any authorized
user object.
The password= and securid= items define authentication methods for the
authorized user.
The password= item has the following subitems:
■
passwd – the plaintext password string; should either be empty (for example, "")
or contain a one-to-eight character password; if this field is non-empty, then the
next subitem (crypt_password=) should not occur.
■
crypt_password=cryptpasswd – (optional) the encrypted version of the plaintext
password string; if this subitem is present, then the plaintext password string
(above) should be empty
■
enabled | disabled – the flag for this simple-text password authentication
method. If disabled, any password presented for authentication of this user is not
compared against this subitem. The default is enabled.
The processing of passwd and crypt_password= subitems is special. When an
authorized user object is first created (or whenever a new password is set for that
user), the password can be presented in plaintext using the (non-empty) passwd
subitem. Thereafter (for example, whenever the object is edited), the
crypt_passwd= subitem can be used to retain a password without having to know
(or retype) the plaintext form.
The encryption method used for these objects is identical to that used by Solaris to
encrypt user passwords (those stored in /etc/shadow). This provides the ability to
clone encrypted passwords from Solaris to SunScreen user descriptions without the
SunScreen administrator needing to know the users plaintext passwords. This fact
also means that the content of the SunScreen authorized user database is maintained
with file permissions that prevent access from all but root users of the SunScreen.
The securid= item has the following subitems:
■
■
“securidname” – User login name associated with this users SecurID token in the
ACE/Server database
enabled | disabled – The flag for this SecurID authentication method. If
disabled, any password presented for authentication of this user is not submitted
to the ACE/Server. The default is enabled.
Note – If both simple-text and SecurID methods exist in a single authorized user
object, the simple-text method should be presented first.
160
SunScreen 3.1 Reference Manual • May 2000
Creating an Authorized User Object
The authorized user object is manipulated using the authuser subcommand of
ssadm edit. authuser takes one of the following verbs:
■
add "name" item... – creates or overwrites an object; takes a complete description
of the object, beginning with its name, followed by desired items and subitems as
defined above.
■
delete "name" – deletes a named object
■
print[,sortopt] ["name"] – display one or more objects; if an object’s name is
given, then only that object’s definition is displayed; otherwise all authorized user
objects are displayed
■
names [,sortopt] – display the names of all objects sortopt can be:
■
■
■
■
■
asc – ascending order by name (case-sensitive)
desc – descending order by name (case-sensitive)
iasc – ascending order by name (case-insensitive)
idesc – descending order by name (case-insensitive)
raw – order stored in database
The default is asc.
The following is an example of what you type to display an existing authorized user
object while logged into the primary Screen:
admin% ssadm -r primary edit Initial
edit> authuser print jeff.hogg
"jeff.hogg" ENABLED PASSWORD={ "" CRYPT_PASSWORD="s8Q2DZRw4tmGk"
ENABLED } DESCRIPTION="large and in charge” REAL_NAME=”Jeff Hogg"
print surrounds the value of each item in double quotes. These are only necessary
on input to protect embedded spaces within the values of items or to preserve null
items.
print produces all tag names in capital letters (for example, REAL_NAME=). On
input, the case for these tags is not important (for example, real_name= and
REAL_NAME= are equivalent.)
Because of the way in which passwords are encrypted, it is unlikely that any add
operation will yield a particular crypt_password= encoding of any given plaintext
password. In fact, there are 4096 different encryptions of any given plaintext
password.
Chapter 9
Authentication
161
The following is an example of what you type to create the above authorized user
object while logged into the primary Screen:
admin% ssadm -r primary edit Initial
edit> authuser add jeff.hogg password={ "4flash" }
description=”large and in charge” real_name="Jeff Hogg"
edit> quit
This shows creation of the object by supplying the simple-text password in the
plaintext form.
An alternate means of creating the above authorized user object, while logged in to
the primary Screen:.
admin% ssadm -r primary edit Initial
edit> authuser add jeff.hogg password={ ""
crypt_password="s8Q2DZRw4tmGk" } description="large and in
charge" real_name="Jeff Hogg"
edit> quit
This shows creation of the object by supplying the simple-text password in its
already encrypted form
In each of the above add operations, the items have been allowed to default to
enabled.
The following is an example of what you type, while logged into the primary Screen,
to re-create the above authorized user object so that it is disabled:
admin% ssadm -r primary edit Initial
edit> authuser add jeff.hogg disabled password={ ""
crypt_password="s8Q2DZRw4tmGk" } description="large and in
charge" real_name="Jeff Hogg"
The following is an example of what you type to create an authorized user object
defining a SecurID authentication method, while logged into the primary Screen:
admin% ssadm -r primary edit Initial
edit> authuser add jeff.hogg securid={ "jeffh" }
description="large and in charge” real_name="Jeff Hogg"
162
SunScreen 3.1 Reference Manual • May 2000
The following is an example of what you type to create an authorized user object
defining both simple-text password and SecurID authentication methods, while
logged into the primary Screen:
admin% ssadm -r primary edit Initial
edit> authuser add jeff.hogg password={ ""
crypt_password="s8Q2DZRw4tmGk" } securid={ "jeffh" }
description="large and in charge" real_name="Jeff Hogg"
The following is an example of what you type to display all authorized user objects,
while logged into the primary Screen:
admin% ssadm -r primary edit Initial
edit> authuser print
"admin" ENABLED PASSWORD={ "" CRYPT_PASSWORD="1hp1R.xm.w63Q"
ENABLED } DESCRIPTION="(created by install)" REAL_NAME="SunScreen
Administrator"
"jeff.hogg" ENABLED SECURID={ "jeffh" ENABLED }
DESCRIPTION="large and in charge" REAL_NAME="Jeff Hogg"
The following is an example of what you type to display the names of all authorized
user objects, while logged into the primary Screen:
admin% ssadm -r primary edit Initial
edit> authuser names,raw
"jeff.hogg"
"admin"
Authorized User Authentication Processing Logic
Authentication processing is performed in the order of authentication methods in
the authorized user object.
First, if the authorized user object itself is disabled, authentication fails.
Second, if the simple-text password method exists and is enabled, then the password
supplied is encrypted and compared against the one stored in the method subitem;
if equal, then authentication succeeds.
Third, if the SecurID method exists, is enabled, and the password presented appears
to be a possible SecurID PASSCODE (that is, ends in 6 decimal digits), then it is
submitted to the ACE/Server along with the securidname for the method; if the
ACE/Server indicates success, then authentication succeeds.
Chapter 9
Authentication
163
If none of the above yields success, then authentication fails.
Administrative User
The administrative user object identifies the SunScreen administrators that
administer the Screen. The administrative user object is, in reality, a role of an
authorized user.
After you create an administrative user object, you grant administrative access by
creating an administrative access rule. The name that you create for the
administrative user object is the same name that you use when you create
administrative access rules.
Proxy Users
Proxy user is a named common object distinct from the authorized user. Proxy users
are either SIMPLE or GROUP objects. SIMPLE objects are used to provide for and
establish an association between individual authorized users and the role they play
in using the facilities controlled by SunScreen. GROUP objects are used to allow
creation of groups of SIMPLE proxy users that share common access to facilities.
Thus, GROUPs streamline the task of allowing or removing access.
Some special proxy user objects also provide the means to map external collections of
users into the access control facilities of SunScreen. In SunScreen, external access to
SecurID users and RADIUS users is provided. (Access to other external user
databases is afforded using RADIUS as an intermediary agent. For example, access
to LDAP user databases stored through Sun Directory Services (SDS) are accessible
through RADIUS.)
FIGURE 9-1 summarizes the relationship between rules, authorized users, proxy users,
and external user databases.
164
SunScreen 3.1 Reference Manual • May 2000
Administration Rule
Authorized User
Proxy User (SIMPLE or GROUP)
Filtering Rule
Proxy User (SIMPLE or GROUP)
SIMPLE Proxy User
unauthenticated
or
Authorized User
or
external (special) user database
GROUP Proxy User
SIMPLE Proxy Users (zero or more)
and, or
GROUP Proxy Users (zero or more)
FIGURE 9-1
Summary of the Relationship Between Rules, Authorized Users, Proxy Users,
and External User Databases
Authorized users and proxy users names are distinct, and you can have objects with
identical names in each. Choose a naming strategy for each set that best reflects the
naming systems already employed. For example, you can choose to name authorized
users by employee identities, like distinguishing names or employee numbers, and
proxy users by names that reflect their normal user login names deployed on server
systems (for example: UNIX login name). Names cannot contain any of the
following characters: !, #, $, %, ^ &, *, {, }, [, ], <, >, ", ', ?, ‘, /, @, or NULL characters.
Space, tab, and other whitespace characters are allowed in names, but in doing so
you should be prepared to supply quotation marks in some situations to protect any
whitespace within names.
Names of authorized users, proxy users, and other user naming items are often
deliberately chosen to be different for purposes of clarity.
FIGURE 9-2 shows the relationship of the proxy user to the authorized user and
backend user name’s password.
The records in the proxy-user database provide the link between the records in the
authorized-user database and the backend user’s name in the server’s user database.
Chapter 9
Authentication
165
Example: Proxy User Name – pu1
Authorized User Name – a1
Authorized User Password – hello
Backend User Name – BkEndUsrName
Authorized User
Database
Records
Proxy User
Database
Backend
FTP Server
Records
Database
<a1, “hello”>
<BkEndUsrName,
BKEndUsrName’s password”>
<pu1, a1, BkEndUsrName>
FIGURE 9-2
ProxyUser Example
Defining a Proxy User Object
The SIMPLE proxy user object is used to define associations between user
authentication mechanisms and the identity a user assumes when connected to a
permitted network resource. This association is loosely dubbed a role.
A SIMPLE proxy user object can indicate one of three types of authentication to be
used: (1) none, (2) an authorized user object, (3) an external authentication
mechanism.
The relationship between SIMPLE proxy users and the authentication mechanism
was shown in FIGURE 9-1.
A SIMPLE proxy user object also indicates the user identity string to be supplied
when establishing the user identity on a network resource. This network resource is
dubbed the backend server and, by derivation, the identity established on the
backend server is defined by the backend_user_name item.
Note – In SunScreen, the backend_user_name is only used by the FTP proxy.
A GROUP proxy user object is a collection of one or more references to other proxy
user objects, either SIMPLE or GROUP.
Any proxy user object, either SIMPLE or GROUP, contains the following items:
166
SunScreen 3.1 Reference Manual • May 2000
■
name – Name of the entity (1 to 255 characters).
■
enabled | disabled – The flag for the entire object; if disabled, authentication
of the associated user is always denied; default is enabled
■
group | simple – The type designator of the object; it is almost always possible
to omit this on input because it can be deduced from the presence of other typespecific items.
■
description="descstr" – (Optional) A demographic string that can be used to
store notations about the role.
A SIMPLE proxy user object contains the following items:
■
radius | securid – (optional) indicates this object is a SPECIAL one, associated
with unrestricted mapping of users from the RADIUS or SecurID system (an
external authentication method).Only one SPECIAL indicator can be present in a
given proxy user object; if present, the next ( auth_user_name= ) item should
not be given.
■
auth_user_name="auser" – (optional) indicates the name of an authorized user
object that is used to authenticate this user role. If it is absent, and if no SPECIAL
item is present, then the proxy user object requires no authentication.
■
backend_user_name="beuser" – gives the backend user name string to supply
when establishing the user’s identity on a backend server. If no SPECIAL item is
present, then this item is required, otherwise it is ignored.
A GROUP proxy user object contains zero or more of the following items:
■
member_name="memname" – Gives the name of another proxy user object that is
a group member.
Note – Although you can add a GROUP proxy user object, including a complete list
of its members, the special commands addmember and deletemember are provided
to edit the membership list of a GROUP.
Creating a Proxy User Object
The proxy user object is manipulated using the proxyuser subcommand of ssadm
edit. proxyuser takes one of the following as commands:
■
add "name" item... – Creates or overwrites an object; takes a complete
(perhaps initial, in the case of GROUP) description of the object, beginning with
its name, followed by desired items, as defined above.
■
delete "name" – Deletes a named object.
■
addmember "grpname" "memname" – Adds a member to an existing GROUP
object; duplicate addmember operations are ignored.
Chapter 9
Authentication
167
■
deletemember "grpname" "memname" – Deletes a member from an existing
GROUP object; attempts to remove an unknown member are ignored.
■
print[,sortopt] ["name"] – Display one or more objects; if an object name is
given, then only that object’s definition is displayed; otherwise, all proxy user
objects are displayed.
■
names [,sortopt] – display the names of all objects; sortopt can be:
■
■
■
■
■
asc – ascending order by name (case-sensitive)
desc – descending order by name (case-sensitive)
iasc – ascending order by name (case-insensitive)
idesc – descending order by name (case-insensitive)
raw – order stored in database
The default is asc.
The following is an example of what you type to display existing proxy user objects,
while logged into the primary Screen:
admin% ssadm -r primary edit Initial
edit> proxyuser print jdh
"jdh" ENABLED SIMPLE AUTH_USER_NAME="jeff.hogg"
BACKEND_USER_NAME="jeffh" DESCRIPTION="Jeff Hogg as self on
Solaris"
edit> proxyuser print proxyusers
"proxyusers" ENABLED GROUP MEMBER_NAME="radius" MEMBER_NAME="jdh"
DESCRIPTION=”users allowed through FTP and telnet proxies”
The following is an example of what you type to create the above SIMPLE proxy
user object, while logged into the primary Screen:
admin% ssadm -r primary edit Initial
edit> proxyuser add jdh auth_user_name=jeff.hogg
backend_user_name=jeffh description="Jeff Hogg as self on Solaris"
edit> quit
You do not have to save these changes before quitting. The following is an example
of what you type to create the above GROUP proxy user object, while logged into
the primary Screen. First create the initial group with no members:
admin% ssadm -r primary edit Initial
edit> proxyuser add proxyusers group description="users allowed
through FTP and telnet proxies"
168
SunScreen 3.1 Reference Manual • May 2000
Note – This above empty group creation demonstrates a case where the GROUP
type cannot be deduced from the other tags, since description= is a tag common
to all proxy user object types.
The next example is what you type to add the members of the example GROUP:
edit> proxyuser addmember proxyusers radius
edit> proxyuser addmember proxyusers jdh
Member names are stored in the order in which you add them to GROUP objects.
The order is unimportant to authentication processing. This example also uses a
SPECIAL object radius that is defined during initial installation.
In each of the above add operations, the items have been allowed to default to
enabled.
The following is an example of what you type, while logged into the primary Screen,
to remove a member reference from a GROUP proxy user object:
admin% ssadm -r primary edit Initial
edit> proxyuser deletemember proxyusers radius
edit> proxyuser print proxyusers
"proxyusers" ENABLED GROUP MEMBER_NAME="jdh" DESCRIPTION="users
allowed through FTP and telnet proxies"
Chapter 9
Authentication
169
The following is an example of what you type to display all proxy user objects,
while logged into the primary Screen:
admin% ssadm -r primary edit Initial
edit> proxyuser print
"admin" ENABLED SIMPLE AUTH_USER_NAME=”admin”
DESCRIPTION=”initial SunScreen administrator”
“admin-group” ENABLED GROUP MEMBER_NAME=”admin”
DESCRIPTION=”SunScreen administrators”
“anonymous” ENABLED SIMPLE BACKEND_USER_NAME=”anonymous”
DESCRIPTION=”unauthenticated user, for anonymous FTP, etc."
"ftp" ENABLED SIMPLE BACKEND_USER_NAME="anonymous"
DESCRIPTION="unauthenticated user, for anonymous FTP, etc."
"jdh" ENABLED SIMPLE AUTH_USER_NAME="jeff.hogg"
BACKEND_USER_NAME="jeffh" DESCRIPTION="Jeff Hogg as self on
Solaris"
"proxyusers" ENABLED GROUP MEMBER_NAME="radius" MEMBER_NAME="jdh"
DESCRIPTION="users allowed through FTP and telnet proxies"
"radius" ENABLED SIMPLE RADIUS DESCRIPTION="default, external,
non-specific RADIUS proxy_user"
"securid" ENABLED SIMPLE SECURID DESCRIPTION="default, external,
non-specific SecurID proxy_user"
The following is an example of what you type to display the names of all proxy user
objects, while logged into the primary Screen:
admin% ssadm -r primary edit Initial
edit> proxyuser names,raw
"admin"
"admin-group”
"anonymous"
“ftp"
"radius"
"securid"
"jdh"
"proxyusers"
Proxy User Processing Logic
In earlier sections, the relationship between authorized user objects and proxy user
objects was described, as well as an introduction of external (SPECIAL) proxy user
authentication methods. This section gives more specifics regarding these objects
and mechanisms, and the sequence of steps performed by the processing logic upon
them.
170
SunScreen 3.1 Reference Manual • May 2000
There are fundamentally two types of authentication processing performed in
SunScreen. Whenever a user identity is required, authentication processing occurs
first, using one of these two processes. After SUCCESS is obtained in the
authentication of an identity you supplied, access control matching determines if the
user is allowed to perform the operation being attempted; authentication FAILURE
denies any requested operation. (Access control is described in the section “User
Access Control Processing Logic” on page 172.)
The first type of processing is the authentication of an authorized user object
directly. This form occurs when authenticating an administrator of SunScreen, either
through the administration GUI Login page or by the ssadm login subcommand.
In these situations, the user name provided must match an ENABLED authorized
user object. Authentication logic has been previously described (see “Authorized
User Authentication Processing Logic” on page 163).
The second type of processing is the authentication of a proxy user object. This form
occurs when authenticating a user who desires access through the FTP or telnet
proxies.
As previously introduced, authentication of a proxy user object can take one of three
subpaths: (1) null authentication, (2) authorized user authentication, or (3) SPECIAL
external authentication method processing.
Regardless of proxy user authentication path, only ENABLED objects can be used
for authentication. A DISABLED object always results in an authentication FAILURE
if attempted.
Null Authentication
Null authentication occurs when a SIMPLE proxy user object named by the user
contains no auth_user_name= item. In this situation, whatever input is given for
the password is accepted without any checking. The pre-installed anonymous and
ftp proxy user objects are examples of this type of authentication.
There is nothing special about the names anonymous and ftp for these preinstalled
objects. You can create additional null authentication proxy user objects and use
them in lieu of or in addition to the preinstalled ones. This allows the creation of null
authentication paths that are private to your installation.
Referenced Authorized User Authentication
Authorized user authentication occurs when an auth_user_name= item is present.
In this situation, Authorized user authentication logic is performed on the
authorized user object named in the item (see “Authorized User Authentication
Processing Logic” on page 163).
Chapter 9
Authentication
171
SPECIAL External Method Authentication
SPECIAL external authentication method processing occurs when you supply an
identity, which is a compound name consisting of a SPECIAL external authentication
method and a backend user name.
The syntax of this compound name is:
/extmethodname/backendusername
For example, compound names that use the pre-installed RADIUS and SecurID
SPECIAL methods might be:
/radius/jeffh
/securid/jeffh
There is nothing special about the names radius and securid in these preinstalled
SPECIAL objects; they are distinguished by their special radius or securid items.
You can create additional SPECIAL authentication methods and use them in lieu of
or in addition to the preinstalled ones. This allows the creation of authentication
paths that are private to your installation, perhaps to hide these paths or to
abbreviate user input.
SPECIAL external authentication logic varies depending upon the method in
question. More specifics about the two external methods (RADIUS and SecurID) can
be found in later sections. There are two means for using SecurID tokens for
authentication: one within the authorized user object, the other through SPECIAL
external proxy user object. The reason for this apparent redundancy lies in the level
of trustedness of the two mechanisms. When using the authorized user path, an
association is formed between a specific SunScreen authorized user object and a
specific SecurID token holder. The SPECIAL external authentication mechanism
allows, in essence, any user that SecurID authenticates to satisfy its rigor.
Thus, depending upon the security requirements of your site, you can choose the
mechanism to employ. Notably, the ability to establish authenticity for purposes of
SunScreen administration is never available to SPECIAL external authentication.
User Access Control Processing Logic
As previously referenced, once an identity is supplied, the would-be user is
authenticated. It is still required that this (now authentic) user be allowed to perform
the operation presently being attempted. The logic that determines the abilities of a
user is loosely termed access control.
172
SunScreen 3.1 Reference Manual • May 2000
As with the initial nature of user authentication, there are two contexts within which
access control is employed: SunScreen administrative activities and usage of
network facilities controlled by FTP and telnet proxies.
Access control logic regarding SunScreen administration is covered in various other
sections of this and other manuals. However, once an administrative user has been
authenticated, access to administrative capabilities is controlled by the
administrative rules for both remote and local use. Within each such rule, a user
name is found. If the authorized user named within the rule matches the
authenticated identity, then access is granted at the level the rule specifies.
Alternatively, the rule can reference a proxy user object; if the authenticated identity
is a member of that proxy user object, then the associated rule-specified access is
likewise allowed.
SunScreen proxies that perform user authentication do so by requiring their rules to
reference a a proxy user object. Once the user-supplied identity has been
authenticated, that identity (which is always a proxy user in this context) is
evaluated to see if it is a member of the proxy user object that the rule referenced; if
it is, then the associated rule matches. (See Chapter 10 “Proxies” on page 191.)
RADIUS User Authentication Details
The RADIUS protocol provides the ability to centralize user authentication databases
for widespread uniform deployment throughout organizations. RADIUS was
originally developed for use by terminal-server devices, but its open specification
and reference implementation have allowed it to achieve a sort of universal joint
interconnection status in the world of external authentication mechanisms. Many
forms of external authentication processing, both proprietary and standard, provide
the ability to configure a RADIUS agent, or gateway.
Among noteworthy mechanisms so endowed are:
■
Security Dynamics ACE/Server Version 3.2 and 3.3
■
Sun Directory Services (SDS)
The SDS gateway facility enables SunScreen to tap into authentication using LDAP
user databases.
With respect to a RADIUS server, the Screen plays the role of a RADIUS Requestor.
Note – The term client becomes confused with clients of SunScreen-provided services
so the term requestor is used. It also describes the relationship between the RADIUS
server and the Screen more accurately.
Chapter 9
Authentication
173
The RADIUS protocol uses UDP datagrams to perform user authentication. Each
RADIUS Requestor is configured with a node secret that is known only to itself and
the RADIUS server(s) from which it expects authentication. That node secret is used
to encrypt requests and to decrypt and authenticate server responses.
The RADIUS protocol in SunScreen comes installed with nearly all parameters
prefigured for immediate use. Four remaining configuration elements needing post
installation attention are:
■
Define address object for the RADIUS servers
■
Define access rules allowing RADIUS protocol access to those servers
■
Configure the RADIUS Requestor to use the defined server address object or
objects
■
Configure the RADIUS Requestor with SunScreen’s RADIUS node secret
The SunScreen RADIUS Requestor can use up to eight different IP addresses for
servers to be queried. These can be configured in one or more address common
objects with arbitrary names.
Tip – Define a single address group object to collect all RADIUS servers for ease in
creating server access rules.
To allow the RADIUS Requestor to function, the Screen must be configured to allow
it access to the server(s) through the radius service Common Object, which comes
pre-installed.
RADIUS Server Configuration
The RADIUS Requestor learns of its RADIUS servers and node secret from the
variables RADIUSServers and RADIUSNodeSecret, respectively.
The RADIUSServers variable can either be global or Screen-specific.
It contains the following items
■ sys=Screen (optional)
■ prg=auth
■ name=RADIUSServers
■ values={ host=server ... }(address object names or IP addresses or both of
one or more RADIUS servers)
■ description="descriptive text" (optional)
■ enabled | disabled (The default is enabled)
For multiple-Screen installations, there are at least two approaches for dealing with
the possible need to have Screens use different RADIUS servers. One is to employ
the SCREEN attribute on address objects with the same name, and then use a global
174
SunScreen 3.1 Reference Manual • May 2000
RADIUSServers variable. Another is to avoid the use of SCREEN attributes on
address objects and instead use the sys= item to create Screen-specific
RADIUSServers variables. Of course, combinations are also possible. And, naturally,
the logic prefers Screen-specific address objects and variables over global ones.
The address object or objects (referenced by server name in the above) can be
GROUP, RANGE, or SINGLE. server can also be a dotted-quad IP address; however,
avoid such usage unless required. The first eight unique IP addresses produced
during processing of the variable are used.
Note – Because of the way SunScreen represents address objects, use of GROUP or
RANGE objects results in server usage that is ordered by ascending IP address. The
preference order of server use can be controlled precisely by the order of the
subitems in the values={...} of the RADIUSServers variable.
RADIUS Node Secret Configuration
The RADIUSNodeSecret variable specifies a character string to use for security and
authenticity when interacting with the configured RADIUS server or servers.
Because of the way RADIUS operates, only the RADIUS Requestors have node
secrets (not the servers).
The same value configured for “RADIUSNodeSecret” must also be introduced into
each RADIUS server through its own configuration mechanism. (For obvious
reasons, this should be done in an out-of-band fashion.)
The “RADIUSNodeSecret” variable is normally Screen-specific. It contains the
following items:
■
sys=screen (Optional)
■
prg=auth
name=RADIUSNodeSecret
value="nodesecret" (node secret string)
description="descriptive text" (Optional)
enabled | disabled (The default is enabled.)
■
■
■
■
In multiple-Screen installations, the sys= item allows you to configure different
node secrets for each Screen.
Caution – Because shortcuts were taken by some reference implementations, a
common deficiency in RADIUS servers is the proper handling of node secrets that
are longer than 31 characters. If you intend to use longer values, determine that your
server or servers can handle them correctly.
Chapter 9
Authentication
175
Once addresses, rules, and variables have been established, the configuration must
be activated to propagate the changes.
Typical RADIUS Configuration
A typical RADIUS configuration scenario has two Screens that each protect a site.
la-screen and la-radsvr are a Screen and RADIUS server in the la location,
sf-screen and sf-radsvr are a Screen and RADIUS server in the sf location.
Each site uses the RADIUS server of the other as a backup.
Note – Ephemeral IP addresses are shown. Encrypted tunnels, or VPNs, are
possible, perhaps likely, in such a configuration, but are not shown for purposes of
clarity.
The following is an example of what you type to create address objects, while logged
into the primary Screen:
admin% ssadm -r primary edit ConfigName
edit> add address la-radsvr HOST 1.2.3.4 ...
edit> add address sf-radsvr HOST 4.3.2.1 ...
edit> add address radsvrs GROUP { la-radsvr sf-radsvr } { } ...
The following is an example of what you type to create a rule to allow
RADIUS Requestor-to-server access, while logged into the primary Screen:
edit> add rule radius localhost radsvrs ALLOW
The following is an example of what you type to create RADIUS variables, while
logged into the primary Screen:
edit> vars add sys=la-screen prg=auth name=RADIUSServers\
values={ host=la-radsvr host=sf-radsvr } description="RADIUS
servers for la site"
edit> vars add sys=sf-screen prg=auth name=RADIUSServers\
values={ host=sf-radsvr host=la-radsvr } description="RADIUS
servers for sf site"
176
SunScreen 3.1 Reference Manual • May 2000
The following is an example of what you type to create RADIUS node secret
variables, while logged into the primary Screen:
edit> vars add sys=la-screen prg=auth name=RADIUSNodeSecret
value=la--secret
edit> vars add sys=sf-screen prg=auth name=RADIUSNodeSecret
value=sf--secret
Save and activate the configuration:
edit> save
edit> quit
admin% ssadm -r primary activate ConfigName
For example, given a valid, RADIUS-hosted user gooduser with password
goodpass and an invalid user baduser, while logged into the Screen la-screen:
admin% ssadm -r la-screen lib/user_authenticate -v /radius/
gooduser
goodpass
User /radius/gooduser authenticated and mapped to backend user
gooduser
admin% ssadm -r la-screen lib/user_authenticate -v /radius/
gooduser
anythingelse
User /radius/gooduser failed authentication.
admin% ssadm -r la-screen lib/user_authenticate -v /radius/baduser
anything
User /radius/baduser failed authentication.
Other vars for RADIUS Configuration
The following additional variables are preinstalled and used to control the RADIUS
client protocol; they are pre-ENABLED and generally need not be altered:
snoop is often used to filter network input during the process of capture or direct
display. logic avoids contacting an unresponsive server for this many seconds:
edit> vars print PRG=auth
PRG="auth" NAME="RADIUSHolddown" ENABLED VALUE="300"
DESCRIPTION="seconds to ignore a non-responsive RADIUS server"
Chapter 9
Authentication
177
snoop is often used to filter network input during the process of capture or direct
display. logic makes this many passes through the server list before giving up:
PRG="auth" NAME="RADIUSRetryPasses" ENABLED VALUE="3"
DESCRIPTION="how many times to try each RADIUS server"
The name of the RADIUS server port, as given in the Service registry:
PRG="auth" NAME="RADIUSService" ENABLED VALUE="radius"
DESCRIPTION="RADIUS service / port # at which to query server(s)"
The amount of time to wait for each response before sending another attempt:
PRG="auth" NAME="RADIUSTimeout" ENABLED VALUE="5"
DESCRIPTION="seconds to await each RADIUS server response"
snoop is often used to filter network input during the process of capture or direct
display. logic attempts to contact only servers that have not been held-down during
the first pass; subsequent passes contact each server regardless of previous nonresponsiveness. During the first pass, each server is contacted twice in a row before
moving onto the next one. During subsequent passes, each server is only contacted
once; a rough upper-bound on the overall time for total failure for all servers is:
# servers TIMES (#passes + 1) TIMES timeout
This is an upper-bound because of the way the first pass avoids recently
unresponsive servers; a lower-bound would be:
# servers TIMES (#passes - 1) TIMES timeout
So, for example, with two servers configured and using the default time-outs, the
overall failure time-out would be less than 2 x (3+1) x 5 = 40 seconds, and greater
than 2 x (3-1) x 5 = 20 seconds
Other RADIUS Protocol Notes
snoop is often used to filter network input during the process of capture or direct
display. implementation only attempts to use authentication; it does not ask the
server to store any accounting information. snoop is often used to filter network
178
SunScreen 3.1 Reference Manual • May 2000
input during the process of capture or direct display. implementation allows for a
single node secret for each Screen. It is theoretically possible to use a distinct node
secret for each server; however, this was foregone in favor of configuration
simplicity whose resistance to basic limitations in the protocol was traded-off against
memory size and computation time.
RADIUS Testing
snoop is often used to filter network input during the process of capture or direct
display. implementation has been tested against a commercial server implementation
provided with BSDIs BSD/OS, Version 3.1. This server appears to be derived from
the Livingston reference implementation and has been tested against a port of the
Livingston reference to Solaris.
Testing is done against Sun Directory Services (SDS) and ACE/Server 3.2 SecurID
authentication.
RADIUS Usage
As discussed in the earlier part of this chapter, the RADIUS authentication
mechanism that is used within SunScreen in the form of a (SPECIAL) External
Method. (See “SPECIAL External Method Authentication” on page 172.)
You can use RADIUS authentication of a user only within the proxy context in
SunScreen. You cannot use RADIUS authentication for authenticating an
administrative user.
RADIUS users are permitted by connecting a SPECIAL proxyuser entity with one or
more proxy policy rules. This connection can be directly in the rule or rules or by
inclusion in a group used in a rule or rules. (See “Proxy Users” on page 164.)
SecurID User Authentication Processing
Details
SecurID is a one-time password mechanism supplied by Security Dynamics
Technologies, Inc. SecurID is a leading form of hardware-based authentication.
Chapter 9
Authentication
179
SecurID authentication involves three components: a user-held hardware device
(token), client software that solicits input from the token-holding user, and server
software that verifies the user authentication information supplied by the tokenholder through the client software. The client software runs on a variety of standard
operating system platforms (those capable of providing user-level security) and
other imbedded system applications. The server software runs on a more restricted
set of standard operating systems.
The client software portion (when installed on the Solaris operating system) is
known by two names: ACE/Client and ACE/Agent. Versions of the Security
Dynamics offering before v3.2 used the former name; version 3.2 and later use the
latter name (the renaming reflects an extension of functionality). Regardless of
version, the server component is known as ACE/Server. ACE/Client or ACE/Agent
software from any version 3.x can properly communicate with any ACE/Server
version 3.x system with a version greater than or equal to it (the client version is less
than or equal to the server version).
SunScreen is compatible with ACE/Server version 3.0.1 and greater.
The SunScreen product does not include the ACE/Server product, which must be
purchased separately.
Typical SecurID authentication involves a hardware device (token) that generates a
pseudo-random value. That value is combined with a personal identification number
(or PIN) to realize a two-factor authentication scheme. The algorithmic data for
computing the pseudo-random value as well as a user’s PIN are (idealistically)
known only to the token-holder and the ACE/Server. There are several styles of
SecurID token device as well as a software implementation, but all operate in
basically the same fashion.
In interfacing SecurID to SunScreen, you are expected to understand the ACE/Agent
and ACE/Server implementation to a level sufficient to install and configure the
SunScreen system as a client of ACE/Server. Further details of the complete SecurID
facility, token types, options, and so forth, should be referred to your ACE/Server
administrator.
ACE/Client, ACE/Agent, and the SunScreen Stub
Client
Configuration of SecurID for use within SunScreen is relatively complex. This
complexity is due partly to the third-party nature of SecurID, partly to a larger
selection of options for its setup and use, and partly because the authentication
provided by SecurID is robust.
180
SunScreen 3.1 Reference Manual • May 2000
The first several sections following this one discuss the various components and
choices for setup that are possible. Those sections are not written in a task-oriented
fashion; rather, they attempt to bridge the gap in understanding SunScreen
mechanisms and the third-party offerings of SecurID.
The section “Typical SecurID Configuration” on page 185 presents an almost
maximal configuration. (A notable simplification is the additional complexities
involving the use of SunScreen SKIP encryption to protect various traffic streams
within the SecurID subsystem.) The setup and initial testing of SecurID depends on
following the applicable steps in that section; it is not merely an example.
The Security Dynamics ACE/Agent software offering is only supported on SPARC
versions of Solaris through version 2.6 (SunOS 5.6). Yet, SunScreen is supported on
Solaris 2.6 and beyond, and on both SPARC and x86 platforms. To complete the
SunScreen support matrix, Sun has developed a stub client installation mechanism.
The stub client allows SunScreen to be configured with a minimum of information
such that it can communicate with an ACE/Server for purposes of authenticating
users of SunScreen-protected resources. The stub client does not provide the full suite
of functions available within the ACE/Agent, nor does it supplant the need to
purchase and deploy the ACE/Server software and SecurID tokens from Security
Dynamics.
In summary, for SecurID support for SunScreen, if you are installing SunScreen on
SPARC-based Solaris 2.6, you can choose either the stub client or the complete ACE/
Agent installation on the Screen. For SunScreen on other platforms or versions of
Solaris, you must use the stub client.
SecurID ACE/Agent
The installation of ACE/Agent can be performed before or after the installation of
SunScreen. The SecurID stub client configuration step can be performed any time
after SunScreen installation. SunScreen does not require SecurID to function, so it is
possible (even recommended) to perform basic installation and configuration of the
Screen first and, once running, add SecurID authentication as needed before fullscale deployment.
For purposes of SunScreen and its usage of SecurID authentication, it is necessary
that the SecurID client software be installed on any Screen(s) that makes use of
SecurID authentication. For example, if only users of proxies are authenticated using
SecurID, then the client software need only be installed on Screens that run proxy
servers. If SecurID is to be used for authentication of SunScreen administrators, then
the client software must be installed on all Screens. It is not necessary to install
SecurID software on the SunScreen Administration Station platform (for remote
administration), nor on the end-systems of users of SunScreen-protected resources
(for example, proxy clients or backend servers).
Chapter 9
Authentication
181
The installation of ACE/Agent is not discussed herein, as it is detailed fully in the
documentation for that product. One important note regarding ACE/Agent use on
SunScreen is that it is not necessary to actually create Solaris user accounts on the
Screens that are protected by ACE/Agent login mechanisms to enable the
authentication of SunScreen users by that Screen. (It is certainly permissible and
recommended to use ACE/Agent authentication to secure the Solaris platform of a
SunScreen system in any way deemed important for administration of that system as
a Solaris platform; but it is not required to make any changes to the Solaris user
configuration to make full use of SecurID within SunScreen itself.)
With those notes, all other issues regarding use of SecurID within SunScreen are
common to both types of client software installation. The following section discusses
the stub client.
SecurID Stub Client
Two files required for the SecurID stub client are loaded onto the Solaris system
when the SunScreen packages are added. They are:
■
/opt/SUNWicg/SunScreen/lib/securid_stubclient_setup
■
/opt/SUNWicg/SunScreen/lib/securid_stubclient.tar
In addition, the stub client installation requires a file called sdconf.rec that is
created on the ACE/Server.
The instructions for creating this file are found in the ACE/Server documentation
and your ACE/Server administrator must provide this file. sdconf.rec contains
addressing information for your ACE/Servers (master and slave) as well as
cryptographic data that enables the SecurID client to establish secure and authentic
communication with the ACE/Server.
When ACE/Server administrators create sdconf.rec, they must first inform the
server of the SunScreen system. The ACE/Server must consider the Screen to be a
client, specifically, a UNIX client system. The ACE/Server must also be configured to
know the IP addresses of the Screen. All of the IP addresses that the Screen will use
to access the ACE/Server must be configured into the server.
Once the above configuration is performed on the ACE/Server and is saved, the
sdconf.rec file contains the information needed to run the stub client installation.
You must get the sdconf.rec file from your ACE/Server administrator and onto
the system.
To complete the stub client installation, you must be root.
182
SunScreen 3.1 Reference Manual • May 2000
Change into the directory where you loaded sdconf.rec and execute the setup
script by typing:
# /opt/SUNWicg/SunScreen/lib/securid_stubclient_setup sdconf.rec
The script creates and deposits a few files into the /opt/ace directory and creates
the /etc/sdace.txt file. It also edits /etc/inet/services to add a pair of
service definitions required by SecurID.
SecurID Access Paths
The protocol used to communicate between the SecurID client and its server(s) is
based on UDP datagrams. This protocol typically uses port 5500, although this can
be altered by changing the configuration on all client and ACE/Server systems.
Awareness of this port number assignment on SunScreen is found in two places:
■
■
/etc/inet/services
Registry service object in the active configuration
The protocol is named securid in both locations.
In more robust SecurID configurations, a slave ACE/Server is configured to serve as
a backup to the master server.
As was previously described, the SecurID client software obtains the IP addresses of
the ACE/Servers from the sdconf.rec file during client installation. Additionally,
the SunScreen policy must contain rules that allow the SecurID client software on
the SunScreen to access the master and slave ACE/Servers. This involves:
■
Address object definition for the ACE/Server(s)
■
Rules to allow the securid protocol access to the ACE/Server(s)
Tip – Define a single Address Group so that it collects both master and slave ACE/
Servers for ease in creating server access rules.
For the master and slave ACE/Server mode to function, all SecurID clients must be
able to access both servers. Additionally, the servers communicate between
themselves, using an additional path through a TCP connection, typically on port
5510; again, this can be altered by changing the configuration on both ACE/Servers.
Awareness of this port number assignment is found in the same places as that of the
UDP datagram securid service; this TCP server-to-server protocol is named
securidprop in both locations.
Chapter 9
Authentication
183
Rules are needed to allow the master and slave servers to communicate using
securidprop.
SecurID PIN Establishment
Part of the use of SecurID tokens involves the establishment of the personal
identification number or PIN. There are a number of variations possible regarding
PIN establishment; these are all determined by the choice of SecurID token device
and ACE/Server administration policy regarding PIN formulation and mode of
establishment.
ACE/Server administrative choice allows the possibility that the token-holder can
establish their own PIN. The experienced SecurID user knows that the standard
ACE/Agent client software allows token-holder PIN establishment using the shell
surrogate program sdshell. SunScreen does not require the use of the shell
surrogate to use SecurID authentication; this avoids the severe security problems
and administrative difficulties that would be associated with creation of user
accounts on the Screen for each token-holder. Each token-holder must nevertheless
be able to establish their PIN.
The SunScreen solution is to provide a daemon process, called the PIN server. This
server is started automatically whenever a policy is activated if the Screen has been
configured as a SecurID client (either through ACE/Agent or stub client
installation). The PIN server normally listens on TCP port 3855 (in the standard
installation). This port number assignment is found in:
■
■
■
/etc/inet/services
Registry service object in the active configuration
/etc/init.d/proxy startup script
In /etc/inet/services, it is named securidpin; in the active configuration, it is
named SecurID PIN. In the proxy startup script, it is referenced by numeric value.
SecurID token-holders use the PIN server to establish a new PIN as necessary.
Access to this server is obtained using a standard telnet client program, specifying
the alternative port number (3855). For example, using the Solaris telnet program:
% telnet Screen 3855
Trying 1.2.3.4...
Connected to Screen.
Escape character is ’^]’.
SunScreen V3.1 SecurID PIN / Re-keying Server
Enter SecurID login: loginname
Enter PASSCODE: passcode
184
SunScreen 3.1 Reference Manual • May 2000
The interaction is familiar to users of the sdshell and to ACE/Server
administrators. Beyond the Enter PASSCODE: prompt, interaction varies
depending upon the state of the SecurID token and the PIN options configured for
that token on the ACE/Server.
An administrative task that must be performed on the Screen is the addition of
policy rules to allow connections to the PIN server from hosts where you think it is
appropriate to allow PIN establishment. For example, you may wish to require PIN
establishment to occur only from hosts behind your Screens and from external hosts
whose traffic is protected by SKIP encryption.
Note – Some SecurID installations may not allow token-holders to do PIN
establishment, opting instead for use of PINs which are determined solely by the
ACE/Server administrator. In such cases, access to the PIN server is not needed.
Typical SecurID Configuration
This section attempts to bring together the various configuration elements described
in previous sections with an example setup that illustrates the pertinent details of
establishing a working SunScreen policy utilizing SecurID authentication.
The example presumes the following pre-existent state:
■
screen is our SunScreen Screen (as well as localhost)
■
admin is our (remote) SunScreen Administration Station
■
A standard Initial policy has been created, with default names for addresses and
SKIP certificates
■
Address objects inside and outside have been created to declare hosts that are
within and without the protection of the Screen, respectively
■
ACE/Servers acemaster and aceslave have been configured
■
screen has been configured as a UNIX client in the ACE/Servers
■
The (resulting) sdconf.rec file has been loaded into the /var/tmp directory on
screen
A standard (non-PINPAD) SecurID token is used, which has been given a login
name of ssadmin; that login has been activated on screen on the ACE/Servers; the
token has been configured for user establishment of a 4- to 8-digit PIN and is in
new-PIN mode.
The overall steps performed are:
■
Stub client configuration
■
ACE/Server address object creation
Chapter 9
Authentication
185
■
SecurID client-to-server policy rule creation
■
ACE/Server server-to-server policy rule creation
■
PIN server policy rule creation
■
Augment the SunScreen administrative user to use SecurID
■
Altered policy activation
■
PIN establishment
■
Screen administrative authentication through SecurID
The command-line interface (using ssadm commands) is shown here for brevity;
however, except for the stub client configuration, all other steps can be performed
using equivalent administration GUI operations.
The following is an example of what you type to perform the SecurID stub client
configuration (while root in a shell on screen):
# cd /var/tmp
# /opt/SUNWicg/SunScreen/lib/securid_stubclient_setup sdconf.rec
The following is an example of what you type to create the registry address objects
to describe the ACE/Servers (while logged in to the Screen):
admin% ssadm -r screen edit Initial
edit> add address acemaster HOST ....
edit> add address aceslave HOST ....
edit> add address aceservers GROUP { acemaster aceslave } { } ...
edit> save
The following is an example of what you type to continue adding the SecurID clientto-server policy rule:
edit> add rule securid localhost aceservers ALLOW
And to add the ACE/Server server-to-server policy rule:
edit> add rule securidprop aceservers aceservers ALLOW
186
SunScreen 3.1 Reference Manual • May 2000
And the PIN server policy rule (actually, two rules are shown being created, one that
allows the end-user SKIP Administration Station to access the PIN server, the other
for unencrypted access for inside hosts):
edit> add rule "SecurID PIN" admin localhost SKIP_VERSION_2 remote
screen.admin DES-CBC RC4-40 MD5 NONE ALLOW
edit> add rule "SecurID PIN" inside localhost ALLOW
Note – These rules should be placed early enough in the policy to preempt other
conflicting (DENY or less-secure) rules.
Now, augment the standard admin user to allow SecurID authentication (the
existing value is first displayed for clarity):
edit> authuser print admin
"admin" ENABLED PASSWORD={ "" CRYPT_PASSWORD="1hp1R.xm.w63Q"
ENABLED } DESCRIPTION="(created by install)" REAL_NAME="SunScreen
Administrator"
edit> authuser add admin password={ ""
crypt_password="1hp1R.xm.w63Q" } securid={ ssadmin }
description="updated for either simple password or SecurID"
real_name="SunScreen Administrator"
Save and activate the augmented policy:
edit> save
edit> quit
% ssadm -r screen activate Initial
Chapter 9
Authentication
187
Now, perform PIN establishment of the token (from the Administration Station):
% telnet screen 3855
Trying 1.2.3.4...
Connected to screen.
Escape character is ’^]’.
SunScreen V3.1 SecurID PIN / Re-keying Server
Enter SecurID login: ssadmin
Enter PASSCODE: 6-digit-passcode-from-token
New PIN required; do you wish to continue? (y/n) [n]: y
Now enter your new PIN, containing 4 to 8 digits, or press Return
to generate a new PIN and display it on the Screen, or end the
connection to cancel the New PIN procedure: 4-digit-PIN
Please re-enter new PIN: 4-digit-PIN
Wait for the code on your token to change, then connect again with
the new PIN
Connection closed by foreign host.
The configuration is now complete. After the code on the token changes (up to one
minute later), administrative access to the Screen can be obtained using SecurID. The
SunScreen administrative user’s name is still admin, but you supply as the
password the 4-digit-PIN value (established above) followed immediately by the 6digit value displayed by the token.
In the example, the simple-text password can also be allowed to establish
administrator authenticity.
Other SecurID Details
Use of SecurID authentication by SunScreen requires the UDP and TCP protocols
and also that the Screen has at least one IP address. This implies that a Screen
configured with no routing-mode interfaces cannot use SecurID authentication (as it
lacks the ability to speak these protocols).
You should exercise caution when deploying SecurID authentication to protect
SunScreen administration (and indeed any other critical SunScreen-control facility
where authentication is required). Because the ability to authenticate using SecurID
requires using policy rules in SunScreen, a mistake in configuring a policy can leave
the Screen in a state where SecurID authentication is broken. Additionally, the ACE/
Server could be down or inaccessible for other reasons, which can result in an
administrative lockout. As a precautionary measure, at least one SunScreen
administrator should always be configured with ALL access and a simple-text
password (perhaps in addition to SecurID).
188
SunScreen 3.1 Reference Manual • May 2000
ACE/Server version 3.2 and newer can be hosted on SPARC Solaris 2.6. Because of
the additional security features of SunScreen, it is tempting to install ACE/Server on
the SunScreen. This is a perfectly acceptable deployment, but you are cautioned to
understand thoroughly the ramifications of installing ACE/Server on a multi-homed
host. There are numerous complexities to be dealt with on an on-going basis if your
SunScreen does not have a single IP address that can service all queries from other
SecurID software components. (See your ACE/Server installation documentation
regarding “Multiple Server IP Addresses.”)
SecurID Usage
As discussed in earlier portions of this chapter, the SecurID authentication
mechanism is used within SunScreen in the form of either an authorized user or a
(SPECIAL) External Method. (See “Authorized Users” on page 158 and “SPECIAL
External Method Authentication” on page 172.)
You can use SecurID to authenticate administrative users as well as to authenticate
authorized users for SunScreen proxies.
Use of SecurID in the authorized user context is provided by configuring authuser
entities to include SecurID references (for example, login names known to the ACE/
Server or Servers).
Use of SecurID in the (SPECIAL) External Method is permitted by connecting a
SPECIAL proxyuser entity with one or more proxy policy rules. This connection
can be directly in the rule or rules or by inclusion in a group used in the rule or
rules. (See “Proxy Users” on page 164.)
Chapter 9
Authentication
189
190
SunScreen 3.1 Reference Manual • May 2000
CHAPTER
10
Proxies
This chapter discusses the proxies used in the SunScreen application. It contains
information on:
■
■
■
■
■
■
How proxies work
Proxy user authentication
FTP proxy
HTTP proxy
SMTP proxy
Telnet proxy
SunScreen Proxies
A proxy is a user-level application that runs on the Screen. The main purpose of
proxies is to provide content filtering (for example, allow or deny Java applets) and
user authentication.
SunScreen lets you set up proxies for FTP, HTTP, SMTP, and Telnet traffic protocols.
Although each proxy has different filtering capabilities and requirements, you can
allow or deny sessions based on source or destination addresses of packets. Proxies
share common objects and policy rule files. To start a proxy, you set up rules for a
proxy in your security policy and activate the policy.
Use of these proxies does not require installing additional client or server system
software. However, some changes may be required in system configurations or usersupplied commands to access protected destinations through the proxies.
The activation process employs a script that checks to see if the policy being
activated contains one or more rules that use a given proxy. If so, the corresponding
proxy is automatically started. If this same script determines that the Screen has
been configured as a SecurID client, then the SecurID PIN server is started as well.
191
FIGURE 10-1 shows a Screen using a proxy to filter packets for the HTTP protocol.
Proxy
Outside
Inside
Screen
Client
Stateful Packet Filtering
My
Machine
DMZ
FIGURE 10-1
Screen With a Proxy
How Proxies Work
Each proxy is a multithreaded program provided with SunScreen. Each is configured
through common objects and policy rules. A particular proxy is initiated or
reconfigured whenever a policy is activated that contains rules that specify its type
of access regulation.
Note – SunScreen proxies require the facilities of TCP and UDP internet protocols.
As such, only Screens with at least one routing-mode (IP-address-bearing) interface
can provide proxy services.
Policy Rule Matching
Each proxy is interposed in the middle of rules that reference it by the rule
compilation process. In proxy rules, as in other Screen rules, you refer to originating
client and destination (or backend) server address objects, not the Screen itself.
192
SunScreen 3.1 Reference Manual • May 2000
Note – The Screen rule compilation process actually produces two subrules for each
proxy-use rule; one that allows client access to the proxy server program, and the
other that allows the proxy server program to access the backend server or servers.
You do not see these rules as they are hidden but effect a similar kernel-based
stateful filtering mechanism to other rules for the Screen. The proxies themselves
employ the original proxy-use rules for their own, more detailed, access control
mechanisms.
In addition to stateful packet filtering within the Screen kernel, each proxy performs
additional rule processing to control access. The additional checking enforces end-toend (client-to-server) address and service matching, as well as user authentication,
command restriction, and content filtering as may be configured.
The general flow of tests that each proxy applies to access requests is:
1. For FTP and Telnet proxies: Has the user been properly authenticated?
Note – User authentication occurs only once, regardless of the number of rules
configured. Authentication is based upon the user identity and accompanying
passwords (if any) supplied by interaction with the client host. See Chapter 9
“Authentication” on page 157.
2. For each rule configured for a particular proxy: Is the requested service port one
that is handled by the proxy?
The proxy only receives connection requests for the port or ports on which it is
configured to listen.
3. Is the address of the client contained in the set of source addresses for the policy
rule?
4. Is the address of the backend server (if applicable) in the set of destination
addresses for the policy rule?
5. For HTTP URL references with specific port numbers: Is the target service port
allowed by the proxy?
6. For FTP or Telnet proxies: Is the authenticated user a member of the GROUP
proxy user specified in the rule?
As with other Screen rules, these tests are performed in the order in which they
appear within the policy. The first rule that matches all tested criteria takes effect
with respect to any incoming request for a proxy-provided service. If no rule is
found that matches all (applicable) criteria, the requested access is denied.
Chapter 10
Proxies
193
Proxy User Authentication
The FTP and Telnet proxies of SunScreen provide the ability to restrict access to
users who can verify their authenticity.
User authentication mechanisms of SunScreen are described in detail in Chapter 9
“Authentication” on page 157. In this section, the discussion is prefaced by notes
that pertain especially to how these user mechanisms are employed by the proxies.
The goals of user authentication within a proxy are to:
■
■
Establish the authenticity of a proxy user
Locate a rule that references that authenticated proxy user
A side-effect of establishing an authentic user is a collateral mapping to a backend
user identity. This identity is a string that is supplied (by the FTP proxy) as the user
of the backend server (for example, a user’s userid on Solaris).
The second goal is achieved by the rule matching steps previously described. A rule
that references the authentic proxy user itself, or that references a GROUP proxy
user that contains an ENABLED member reference to that authentic proxy user,
causes a successful user match.
Proxy Limitations
Proxy implementation has the following limitations:
■
Proxies can only be used on Screens with at least one routing-mode interface.
■
You cannot use proxies on Screens in an HA cluster.
Save Is Not Required With Certain Common
Objects
The following common objects that appear in the administration GUI are
automatically saved when they are edited or new objects are added.:
■
■
■
■
■
194
Authorized user
Administrative user
Proxy user
Jar hash
Jar signature
SunScreen 3.1 Reference Manual • May 2000
You do not need to save these objects. Once these objects are added or edited, the
change applies immediately and cannot be reversed. The Save button in the
administration GUI is greyed out to show that it is inactive.
Note – Although the changes made to these objects are saved immediately, they do
not take effect until a policy is activated. The administration GUI edits authorized
users, which are authuser objects; administrative users, which are adminuser
objects; or proxy users, which are proxyuser objects; and Java archive (Jar) hashes
and Jar signatures.
FTP Proxy
The FTP proxy functions as a relay for the File Transfer Protocol to let you control
connections based upon source and destination addresses and user authentication. It
can also limit access to certain file transfer commands, such as put and get, based
on source or destination addresses and user authentication.
You can configure the FTP proxy to ask for user authentication as an additional
mechanism for controlling access to sites and commands.
FTP Proxy Operation
When the FTP proxy starts, it reads its policy files and then listens on the standard
FTP port (port 21) for connections. When a connection is made, the FTP proxy starts
a new thread to handle the connection, and the main thread returns to listening for
other connections.
The child thread generates an FTP login banner and asks for a user name and
password pair. The user name format is proxyuser@server. The password format
is proxypass@serverpass, where proxypass is the password for the proxy, and
serverpass is the password for the destination FTP server.
The FTP proxy validates the proxyuser name using proxypass as was described
previously. The hostname (backend server), given in the USER command after the
first @ character, is translated to its IP address(es) using the hostname-to-address
translation mechanism configured for and in the context of the FTP proxy. The
resulting addresses provide the values to use as matching criteria for the destination
addresses in the proxy rules.
Chapter 10
Proxies
195
The standard proxy rule matching (given in the section “Policy Rule Matching” on
page 192) is used. If a match is found, a connection is established to the FTP server
of the user-requested destination. If multiple addresses result from the translation of
the user-specified backend server, they are each tried in the order yielded by the
name translation mechanism (for example, DNS).
Once a connection to the backend server is established, the proxy attempts to log in
using the backend username generated during authentication and using
serverpass as the password (see the section “Proxy User Authentication” on
page 194). Once the backend user identity is established, commands that are allowed
by flags associated with the policy rule in use are relayed, results returned, and files
exchanged.
The following example illustrates a session between an FTP connection to a target
host (ftp.cdrom.com) using anonymous FTP.
#ftp screen
Connected to screen
220- Proxy: SunScreen FTP Proxy Version 3.1
:Username to be given as proxy-user@FTP-server
:Password to be given as proxy-pass@FTP-server-pass
220 Ready
Name (screen:edison): [email protected]
331-Proxy: Authenticate and connect
331 Password needed to authenticate anonymous.
Password:
:Authentication mapped anonymous to backend user anonymous
:Connecting to ftp.cdrom.com (165.113.121.81) - done
Server: 220 wcarchive.cdrom.com FTP server (Version 2.0) ready
Proxy: Login on server as anonymous
Server: 331 Guest login OK, send your email address as password
Proxy: Supplying password to server
230-Server:
230-Welcome to wcarchive - home ftp site for Walnut Creek CD-ROM
230-There are currently 2273 users out of 2750 possible
230 Guest login OK, access restrictions apply
FTP Proxy and Anonymous FTP
The proxy user anonymous is configured during the installation process as an
unauthenticated proxy user. As such, any string provided before the first @ in the
password is ignored. The password after the first @ in the password sequence (that
is, [email protected]) is the backend user password, which, for anonymous FTP,
is traditionally the user’s email address.
196
SunScreen 3.1 Reference Manual • May 2000
FTP Proxy Use
To use the proxy and make FTP connections, the user must open an FTP connection
to the Screen (as shown in the preceding example) rather than open a direct
connection to the end system. The Screen’s policy rules only allow FTP connections
to and from the FTP proxy.
Other FTP Proxy Issues
The FTP proxy does not permit the PASV command (used for third-party transfers).
The FTP proxy has a 10-minute time-out on the control connection for user requests.
The responses from the backend server have only two minutes to arrive before
timing out.
The maximum number of concurrent sessions available in the FTP proxy daemon is
configurable through the variable N_Sessions.
It contains the following items:
■
sys=Screen (Optional)
■
prg=ftpp
■
name=N_Sessions
■
values=max # of sessions
■
description="descriptive text" (Optional)
■
enabled | disabled (The default is enabled)
As initially installed, a global version of this variable is created that restricts the
number of concurrent sessions to 100.
The following is an example of what you would type to display this (initial) variable
while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> vars print prg=ftpp name=N_Sessions
PRG="ftpp" NAME="N_Sessions" ENABLED VALUE="100"
DESCRIPTION="limit # of concurrent sessions, FTP proxy"
You can alter this number of sessions, perhaps to be more restrictive, on a particular
Screen.
Chapter 10
Proxies
197
The following is an example of what you would type to do this while logged in to
the primary Screen:
edit> vars add sys=Screen prg=httpp name=N_Sessions value=66
description="limit # of concurrent sessions on the Screen FTP
proxy"
edit> quit
By configuring the FTP proxy on a Screen, the actual FTP service into that system
becomes unavailable. To avoid confusion, define the destination address of proxy
rules to exclude all the addresses of your Screen or Screens. (You can still FTP out of
the Screen, as necessary.)
HTTP Proxy
The HTTP proxy as currently implemented is a means of filtering Web content for
outbound references from Web browsers to external, unknown servers. It does not
have the ability to restrict inbound access such as user access control.
The HTTP proxy:
■
Provides a relay capability for HTTP access to the World Wide Web. This relay
supports HTTP and the Secure Sockets Layer (SSL).
■
Allows or denies sessions based on the source and destination addresses.
■
Provides selective filtering of HTTP content (such as Java applets, Active-X, and
cookies) based on the source and destination addresses for sessions.
■
Is useful in implementing NAT because it originates all outbound connections to
Web servers. It reuses a single IP address for multiple browser clients.
■
Can filter Java applets based on the signatures encapsulated in Jar files attached
to the applet or based on a precomputed hash of valid applets.
■
Is configured on a per-rule basis in the configuration editor to:
■
■
■
■
Remove cookies (see the section “HTTP Proxy Limitations” on page 204)
Block Active-X content
Block or allow all Java content (see the section “HTTP Proxy Limitations” on
page 204)
Block SSL content.
To use the HTTP proxy, define the source addresses that should be allowed to have
access to the proxy and to the destination addresses of allowed Web servers to be
contacted. To create the HTTP proxy rule, use the built-in service www, reference your
198
SunScreen 3.1 Reference Manual • May 2000
desired source and destination addresses, and select the PROXY for PROXY_HTTP
during rule definition (in the administration GUI) or the PROXY_HTTP keyword (for
command-line rule creation).
The HTTP proxy allows further restrictions based on target port numbers. HTTP
provides for user-specified references to arbitrary port numbers using the http://
host:port/... construction. Because of the way in which the Screen operates,
client browsers can be inadvertently allowed access to services that would otherwise
be restricted save for this feature of HTTP.
The port restriction mechanism for the SunScreen HTTP proxy is controlled by the
variable TargetSvcs. This variable can either be global or Screen-specific. It contains
the following items:
■
sys=Screen (Optional)
■
prg=httpp
■
name=TargetSvcs
■
values={ svc=service... }(name or names of service objects for services to
allow)
■
description="descriptive text" (Optional)
■
enabled | disabled (The default is enabled.)
As initially installed, a global version of this variable is created that restricts such
access to port 80 (the www service).
The following is an example of what you would type to display this (initial) variable
while logged into the primary Screen:
admin% ssadm -r primary edit Initial
edit> vars print prg=httpp name=TargetSvcs
PRG="httpp" NAME="TargetSvcs" ENABLED VALUES={ svc="www" }
DESCRIPTION="target TCP ports that the HTTP proxy can get to"
Chapter 10
Proxies
199
You may wish to be able to have access to a wider range of ports. One such
configuration is obtained by configuring a new service object and an added variable
(for example, this time, for a particular Screen). The following is an example of what
you would type while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> add service www-targets SINGLE FORWARD "tcp" PORT 1024-1520
PORT 1522-3850 PORT 3856-5999 PORT 6064-65545 COMMENT "more TCP
port numbers to allow as targets in HTTP proxy URIs"
edit> vars add sys=screen prg=httpp name=TargetSvcs values={ svc=ssl
svc=www svc=www-targets } description="target TCP ports that the
HTTP proxy can get to"
edit> save
edit> quit
Note – The above definitions prevent access to ports that are below 1024 except for
www and ssl. It also prevents access to port 1521 (SQLNET), ports 3851 through 3855
(the Screen’s administrative and SecurID PIN server ports), and ports 6000 through
6063 (used by X Windows). Tailor your restrictions to suit your security needs.
The SunScreen HTTP proxy can also be configured to restrict Web content to be
allowed through. Content can be blocked or allowed, or it can be configured to
verify certain content (Java applets) based on digital signatures or hashes. These
content-filtering features are configured as part of the rules employing the HTTP
proxy.
HTTP -> FTP Proxy: The ftp:// Method
The HTTP proxy relays access for the ftp:// method to the FTP proxy. This enables
users of the browser to list directories and download files. Most often, this facility is
employed in conjunction with URLs embedded in web content designed to facilitate
file downloading.
The standard form of an ftp:// method URL is as follows:
ftp://user:passwd@host:port/path...type
The user, passwd, port, and type are optional (and not often used by ftp:// method
references.) The list of dir components specifies path name of the reference.
SunScreen does not implement the port option for ftp:// URLs.
The default behavior of the user and passwd references is to use “anonymous” FTP. A
typical URL would then look like:
200
SunScreen 3.1 Reference Manual • May 2000
ftp://codebloat.com/pub/dwnlds/exploder5.exe
Control over the defaulting of user and passwd is obtained using three variables.
1. FtpPwdDomain contains the following items:
■
■
■
■
■
■
sys=screen (Optional)
prg=http
name=FtpPwdDomain
value=domain (domain is used in creating an anonymous password.)
description="descriptive text" (optional)
enabled | disabled (The default is disabled.)
The HTTP proxy will default this variable at run-time (if not found, or disabled)
to be the domain name of the Screen (for example, the output of the Solaris
defaultdomain command).
2. FtpPwdUser contains:
■
sys=screen (Optional)
■
prg=http
■
name=FtpPwdUser
■
value=user (user is used in creating an anonymous password. The default is
webproxy.)
■
description="descriptive text" (Optional)
■
enabled | disabled (The default is enabled.)
The HTTP proxy will use this variable, in conjunction with the (perhaps
defaulted) value of FtpPwdDomain to construct an anonymous password of the
form:
@FtpPwdUser@FtpPwdDomain
If the passwd supplied in the URL is a string that contains no @ characters
(encoded as %40), then that passwd string takes the place of the value of
FtpPwdUser in the anonymous password construction. Thus the URL:
ftp://:[email protected]/pub/dwnlds/exploder5.exe
enables designating the user bob for the user portion of the anonymous password
(for example, @bob@FtpPwdDomain).
The value of the FtpPwdUser can be changed to redirect potential email responses
from FTP servers to an appropriate storage receptacle.
3. FtpUser contains:
■
sys=screen (Optional)
■
prg=http
■
name=FtpUser
Chapter 10
Proxies
201
■
value=proxyuser (proxyuser is used in anonymous access. The default is
anonymous.)
■
description="descriptive text" (Optional)
■
enabled | disabled (The default is enabled.)
This variable would not normally need to be altered, unless the identity of the
predefined user anonymous in the Screen’s proxyuser database has been
changed.
In addition to the anonymous usage, it is possible to download using
authenticated users through the FTP proxy using the ftp:// method. An
example URL is:
ftp://proxyuser:proxypass%40serverpass@server/README.TXT
This performs an operation identical to a direct interaction with the FTP proxy,
supplying the user as proxyuser@server and the password as
proxypass@serverpass.
To enable the HTTP proxy to use the ftp:// method, one or more rules are needed
to allow the HTTP proxy itself to be a client of the FTP proxy. The HTTP proxy
always connects to the FTP proxy using the LOOPBACK (127.0.0.1) address. So,
for example, to enable the ftp:// method anonymous access to “outside” web
servers:
edit> add address outside ...
edit> add address local127 RANGE 127.0.0.1 127.255.255.255 ...
edit> add rule ftp local127 outside ALLOW PROXY_FTP \
USER anonymous PROXY_FTP GET CHDIR ...
This enables anonymous FTP through the proxy for any user actually on the Screen
itself as well.
HTTP Proxy Operation
When the HTTP proxy starts, it reads its policy files, starts a Java Virtual Machine
(JVM) for processing Jar files, and then listens on the standard HTTP port (80) for
connections. When a connection is made, the HTTP proxy starts a new thread to
handle the connection, and the main thread resumes listening.
The child thread reads the first line of the HTTP header request from the client and
parses the actual destination address. The method (for example, http:// or
ftp://) is determined. If the ftp:// method has been requested, the request for
202
SunScreen 3.1 Reference Manual • May 2000
file retrieval is forwarded to the FTP proxy as described above. Otherwise (for the
http:// method) the thread searches the proxy policy rules for a match on the
source and destination addresses.
■
If a match is found, the flags associated with that policy rule are set. The proxy
then reads the rest of the client’s HTTP request. If a match for the connection is
not found, the HTTP proxy sends the client an error (Method Not
Implemented) and closes the connection.
■
If cookies are disallowed, any cookie responses are deleted.
■
If SSL is allowed and the connection uses SSL, the connection continues. No
further processing can take place, since the rest of the connection is encrypted. If
SSL is not allowed, the HTTP proxy drops the connection and sends an error
(Method Not Implemented) to the client.
■
If the connection is allowed, the HTTP proxy attempts to open a connection to the
actual destination web server. If the web server cannot be reached, the proxy
returns an error (Cannot locate host) to the client and closes the connection.
■
If the HTTP proxy connects to the web server, it sends the client’s HTTP request
to the server and waits for a response. When a response arrives, the proxy reads
the response header and, if appropriate, drops any cookie requests. If the
response header indicates the response includes Java or Active-X content, the
proxy examines the response body to determine the nature of the content. If the
content is not allowed, the proxy sends an error (Cannot connect to host)
to the client and drops the connection.
Java Virtual Machine (JVM)
If the body contains a Jar file, the Jar is passed to the JVM, which extracts the
signature components and calculates a hash for the Jar. The signatures are compared
to the list of approved signatures and if the signatures match and signed Jars are
allowed, the data are passed on to the client. If hashed Jars are allowed, the proxy
compares the computed hash to the list of approved hash values, and, if a match is
found, passes the response to the client.
After all of the data have been passed to the client, the proxy closes the connections
to the client and the server and terminates the thread.
Jar Hashes and Signatures
The HTTP proxy is configured on a global basis in the configuration editor to verify
the list of acceptable signatures and hash values on Jar content.
Both the Jar hashes and signatures are stored in the vars database.
Chapter 10
Proxies
203
Note – Currently, there is no provision to create Screen-specific versions of the Jar
hashes and signatures for the Screen
Jar Hashes
The following is an example of what you would type to manage Jar hashes:
edit> jar_hash parameters ...
You can add, delete, list, and rename Jar hashes. You assign the names, which are
ephemeral strings. They are used only for purposes of reference to items when
managing them using the jar_hash command.
Jar Signatures
You can add, delete, list, or rename Jar signatures. You assign the names, which are
ephemeral strings. The names are used only for purposes of reference to items when
managing them using the jar_sig command.
HTTP Proxy Limitations
Jar validation facilities acquire the hash and signature values that are added to the
configuration.
Active-X filtering currently blocks certain types of Java content.
SMTP Proxy
The SMTP proxy provides a basic level of control over incoming electronic mail that
is based on the Simple Mail Transport Protocol (SMTP). It can be configured to allow
or deny such email based on source addresses, the actual server name of the source
host, or the server name of the (claimed) originator of a message. It can be further
configured to allow or deny relaying of email based on the destined host or server of
a message.
204
SunScreen 3.1 Reference Manual • May 2000
SMTP Proxy Operation
When the SMTP proxy starts, it reads its policy files, determines its local server
name for use in relay checking, and listens on the standard SMTP port (25) for
connections. When a connection is made, the SMTP proxy starts a new thread to
handle the connection, and the main thread resumes listening.
The child thread takes control of the connection from the client. It then attempts to
reverse-translate the address of the client (from the connection state) to yield a
registered name.
If a registered name is discovered, then the suffixes in the mail_spam list are
checked against that name. If a suffix matches (the end of) the name of the
originating host, the connection is closed with a response (455) refusing reception.
If no name is registered for the address, then the address itself is sought in the
mail_spam list (looking for items that contain a single address or a range). If a
match is found, the connection is closed with a response (455) refusing reception.
Having passed the peer-address check, the proxy thread next attempts the typical
proxy rule match steps (given earlier), except that only the source address is
checked. For each rule that matches, an SMTP connection is attempted to the Mail
Transfer Agents (MTA) listed as destination for the rule.
Once a connection to a destination server MTA has been established, data are
relayed between the client and server MTAs. The content is scanned for commands
that introduce source mailbox, destination mailboxes, and the data stream itself.
Source mailboxes are checked against the spam list (if any). The destination
mailboxes are checked against the relay list
Spam Control
Unsolicited electronic mail is colloquially known as spam. The restriction of mail
based on originator is known as spam control. The SMTP proxy provides the ability
to define a list of one or more restrictors that operate based on either server name
(suffix) or non-server (address range) criteria.
Spam restrictors have one of two syntactic forms:
■
server suffix (suffix in a named host), or
■
start address [.. end address] (range of one or more IP addresses of unnamed hosts)
Note – No spaces are permitted around the double dots (..) in this construct for the
address range.
Chapter 10
Proxies
205
server suffix is simply an ASCII character string.
See the section “SMTP Proxy Operation” on page 205 for details regarding how these
restrictors are used.
Spam restrictors are defined using the command-line interface, and the mail_spam
subcommand of ssadm edit in the administration GUI.
The following is an example of what you would type to display the current set of
spam restrictors while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> mail_spam list
"total-nonsense.org"
"0.0.0.0..255.255.255.255"
The above example listing shows two entries, one to refuse email from the server or
servers with registered address in the domain total-nonsense.org, the other to
refuse mail from any host that does not have a registered server name (in a reversemapping of IP address to DNS name).
The following is an example of what you would type to add an additional restriction
while logged in to the primary Screen:
edit> mail_spam add complete-spam.net
edit> quit
The following is an example of what you would type to remove a restriction while
logged in to the primary Screen:
edit> mail_spam delete lite-spam.com
From the command line, in addition to controlling incoming spam destined for your
site, another important area of control over email is the limitation on accepting email
and then relaying it to another location. Relayed mail is responsible for a great deal
of the unsolicited email on the Internet. Improper relaying makes spam harder to
defeat and leaves the relaying site open to various types of reprisal from the ultimate
recipient-victims.
The SMTP proxy allows the configuration of a set of strings that, coupled with
policy rules, enables you to restrict the destination domains that the proxy accepts.
206
SunScreen 3.1 Reference Manual • May 2000
Relay Control
Relay restrictions have one of two syntactic forms:
domain suffix (suffix in recipients to allow)
■
or
■
!domain suffix (suffix in recipients to disallow)
domain suffix is simply an ASCII character string.
See the section “SMTP Proxy Operation” on page 205 for details regarding how these
restrictors are used.
Relay restrictors are defined using the command-line interface, through the
mail_relay subcommand of ssadm edit. The following is an example of what
you would type to display the current set of relay restrictors while logged into the
primary Screen:
admin% ssadm -r master edit Registry
edit> mail_relay list
"your-domain.com"
"!private.your-domain.com"
This listing shows two entries, one to set a base domain to allow in recipients, the
other to block a private subdomain in recipients.
The following is an example of what you would type to add an additional restriction
(while logged into the primary Screen):
edit> mail_relay add !lists.your-domain.com
edit> quit
The following is an example of what you would type to remove a restriction while
logged into the primary Screen
edit> mail_relay delete !test.your-domain.com
Note – If relay checking is enabled (for example, NO_RELAY) and yet no relay
restrictors are configured, the SMTP proxy defaults to allow only the domain
configured for the Screen itself as the valid domain for inbound mail.
Chapter 10
Proxies
207
The SMTP proxy rules should use the smtp service, and specify the PROXY to be
PROXY_SMTP during rule definition in the administration GUI. (Or the PROXY_SMTP
keyword (for command-line rule creation). The RELAY (or NO_RELAY) flag is used to
specify whether to perform unrestricted versus restricted relaying of mail. Use
NO_RELAY in conjunction with the mail_relay restrictors shown above to effect
relay control.
The following is an example of what you would type, presuming that you already
have the following objects defined:
admin% ssadm -r primary edit Initial
edit> list address
“mta-primary” HOST 1.2.3.4 ...
“mta-secondary” HOST 1.2.3.5 ...
“outside” GROUP { } { inside } ...
The following is an example of what you would type to define an address group to
contain all inside MTAs:
edit> add address mtas GROUP { mta-primary mta-secondary } { ... }
The following is an example of what you would type to define relay restrictors to
specify the servers (and perhaps hosts) to be allowed in recipient mailbox names:
edit>
edit>
edit>
edit>
mail_relay
mail_relay
mail_relay
mail_relay
add
add
add
add
prime-server.com
other-server.com
!lists.prime-server.com
!private.other-server.com
The following is an example of what you would type to define spam restrictors to
deny mail from some mail originators you know to be sources of unsolicited mail:
edit> mail_spam add 0.0.0.0..255.255.255.255
edit> mail_spam add dialups.naughty-isp.net
Finally, the following is an example of what you would type to define a rule to cause
inbound email to pass through the SMTP proxy:
edit> add rule smtp outside mtas ALLOW PROXY_SMTP NO_RELAY
edit> save
edit> quit
208
SunScreen 3.1 Reference Manual • May 2000
Note – Because of the way that SunScreen represents addresses (in numerical order
by IP address), rules that refer to multiple destination addresses give rise to
attempting the MTA connection in numerical order. To obtain finer control over
MTA connection ordering, use multiple rules.
Once a connection is established to a willing backend MTA, the proxy thread begins
watching information passed by the client to the server (ordinarily, the proxy does
not talk to the client). The proxy looks for a MAIL FROM: command from the client.
(This command gives the name of the user who originated the message. It is often
abused by spam message creators, so its use is often untrustworthy.) The mailbox
name in this command is compared with the suffixes in the mail_spam list and if
found there, the connection is aborted with a response (455) refusing reception.
Next, the proxy thread looks for one or more RCPT TO: commands from the client.
(Such commands give one of the destination mailboxes to which the message is
directed. Unlike the MAIL FROM: command, this mailbox name is always a real
recipient.) If the rule specifies NO_RELAY, then the mailbox names in these
commands are compared against the mail_relay list. The search can be
conceptually thought of as a two-pass search. On the first pass, any denial suffixes
(ones beginning with !) are sought and if matched, cause a connection abort with a
response (454) refusing reception. On the second pass, allowance suffixes are sought
(ones not beginning with !). If one matches, the recipient is allowed; if none matches,
the connection is aborted with a response (454) refusing reception.
SMTP is designed to allow multiple messages (each with one or more recipients) to
pass on a single connection. Barring a refusal of service, once all messages have been
passed, the proxy closes the connection to the client and backend server and ends
the child thread.
Other Mail Configuration Issues
In addition to specifying SunScreen SMTP proxy policy, configuration steps must be
taken to cause SMTP-based email to arrive at the proxy for delivery to the servers it
is to represent. The typical mechanism is to create MX records in the Domain Name
System (DNS) for those servers. The procedure for altering DNS configuration is
outside the scope of this document but should be very familiar to your DNS
administrator.
More than one Screen can be configured to operate in parallel to service incoming
mail. The multiple Screen management features of SunScreen make doing so a
relatively straightforward task. These parallel Screens can then be used within MX
records.
Chapter 10
Proxies
209
By configuring the SMTP proxy on a Screen, the actual SMTP (inbound email)
service into that system becomes unavailable. (You can still send email out of the
Screen, as necessary.)
SMTP Proxy Rules
After configuring the content filtering, the final step is to create one or more rules
that actually allow SMTP-based email to be served. A typical configuration often
allows outside email to be filtered through the proxy to one or more inside message
transfer agents (MTA) such as Solaris mail servers.
The source address for SMTP proxy rules should allow mail from any potential mailsending address. Restrictions on source addresses in the rule can be useful in
blocking entirely-abusive mail-originating sites that are stationary with respect to IP
addressing.
The destination address for SMTP proxy rules should contain the addresses of one or
more MTAs to which the proxy will connect to actually store and forward the
incoming email.
Telnet Proxy
The Telnet proxy provides a virtual terminal relay. It allows or denies connections
based on source and destination addresses. The Telnet proxy can ask for user
authentication as an additional mechanism for controlling access to sites and
commands. The Telnet proxy does not support content filtering.
To authenticate users, the Telnet proxy can request a user name from a user and,
based upon the type of authentication for that user name, request and validate a
reusable password or digital token.
Telnet Proxy Operation
When the Telnet proxy starts, it reads its policy files and listens on the standard
Telnet port (23) for connections. When a connection is made, the Telnet proxy starts
a new thread to handle the connection, and the main thread returns to listening.
The child thread generates a proxy login banner and waits to read the user name
and password. The format for user names consists of a login ID and a destination
host separated by an @ symbol; for example, [email protected]. The
210
SunScreen 3.1 Reference Manual • May 2000
Telnet proxy validates the user name/password. If an invalid user name/password
is sent, the Telnet proxy sends an error to the user and closes the connection. If the
user name/password is valid, then the source and destination addresses are checked
against the Screen’s policy rules. If a match is found, the flags associated with that
policy rule are checked. If the connection is permitted, the Telnet proxy opens a
connection to the actual destination server and relays data between the source host
and the destination host.
The hostname (backend server) given in the user prompt, after the @ character, is
translated to its IP address(es) using the hostname-to-address translation mechanism
configured for and in the context of the Telnet proxy. The resulting addresses
provide the values to use as matching criteria for the destination addresses in the
proxy rules.
The standard proxy rule matching (described in the section “Policy Rule Matching”
on page 192) is employed. If a match is found, a connection is established to the
Telnet server of the user-requested destination. If multiple addresses result from the
translation of the user-specified backend server, they are each tried in the order
yielded by the name translation mechanism (for example, DNS). Once a connection
to the backend server is established, all data is relayed (uninspected) by the thread
in both directions until either end terminates.
Other Telnet Proxy Issues
The Telnet proxy used TCP keep-alives on the connection to the client. The Telnet
proxy insists on doing its own echoing during the initial user authentication portion
of the session. Some Telnet client programs do not obey standard Telnet echo
negotiation and improperly double-echo username/hostname input and single-echo
the password.
Note – By configuring the Telnet proxy on a Screen, the actual Telnet service into
that system becomes unavailable. To avoid confusion, define the destination address
of proxy rules so as to exclude all of your Screen(s) addresses. (You can still use the
rlogin protocol to access the Screen, as necessary, as well as being able to telnet
out.)
Chapter 10
Proxies
211
Telnet Proxy Use
Before a client can connect to a remote host when the Telnet proxy is active, the
client must first connect to the Telnet proxy. In the following example, the Telnet
proxy is running on the host Screen, and the user wants to connect to the remote
system foo.com.
riyal% telnet Screen
SunScreen telnet Proxy Version: 3.1
Username@Hostname: [email protected]
At the password prompt, you type the password for the proxy authentication. The
Telnet proxy would compare the specified user name and password to the list of
valid proxy users and their passwords. If the user name/password are correct and
the connection is allowed, the user is presented with a login banner for the machine
foo.com.
Using SKIP Encryption with Proxies
You can have the Screen decrypt incoming traffic from a client before passing it to
the proxy. It requires two rules. The following is an example of using the Telnet
proxy with SunScreen SKIP:
edit> add rule telnet proxyclient localhost SKIP_VERSION_2 ...
edit> add rule telnet proxyclient proxyserver PROXY_TELNET
Likewise, you can have the Screen encrypt the connection from the proxy to the
backend server using a similar pair of rules:
edit> add rule telnet localhost proxyserver SKIP_VERSION_2 ...
edit> add rule telnet proxyclient proxyserver PROXY_TELNET
212
SunScreen 3.1 Reference Manual • May 2000
CHAPTER
11
Logging
This chapter contains information on:
■ Packet logging
■ Log file locations
■ Configuring traffic log size
■ Retrieving and clearing logs
■ Log statistics
■ Inspecting and browsing logs
■ Enhancement
■ Log macros
Packet Logging
SunScreen provides flexible logging of packets. This means that each primary and
secondary Screen keeps a log of its traffic. Logs of the packets are kept on the Screen
that passed or rejected the packets.
You can configure Screen to log a packet when it matches a rule or when it does not.
Most frequently, packets matching DENY rules or packets that are dropped because
they do not match any rule are logged. The action defined in a rule controls whether
a packet is logged and what information about the packet is recorded.
Examining logged packets is useful when you are trying to identify the causes of
problems during configuration or administration. You should also examine logs
periodically for evidence of attempts to break into your network.
Each machine in an high availability (HA) cluster logs what that system passed or
rejected, as well as any locally processed nonpacket events.
The active Screen in an HA cluster will log packets. As log entries become more
extended, such events as nonpacket and nonsession entries in the logs of the passive
Screens appear.
213
Logging Limitations
The following limitations apply to logging:
1. During a situation or time when there is excessive traffic through the Screen, not
all packets are logged.
This logging limitation is an isolated instance and depends on how fast your
system runs.
2. Decrypted packets are logged, but SKIP certificate IDs are not logged.
3. Only the active system logs packets.
When the active HA cluster Screen fails, its logs become inaccessible, and the new
active HA cluster Screen begins logging the packets.
Save Is Not Required With Certain Common
Objects
It is not necessary to type save before quit if only authuser, adminuser,
proxyuser, logmacro, or vars entities are altered. The following is an example of
the nonfatal message you see if you attempt to save without changing entities other
than these types. You can simply quit the configuration editor:
edit> save
lock not held
failed (status 244)
These items are available for immediate use on the Screen where they have been
defined. It is not necessary to activate each change in a log macro to use it. However,
to propagate log macro definitions from a primary Screen to secondaries, you must
activate the configuration.
Log File Locations
SunScreen stores its log files in the following locations:
214
■
The SunScreen packet, session, and extended event log is stored on the Screen in
the /var/opt/SUNWicg/SunScreen/logs directory.
■
SKIP logs are kept in the /var/log/ directory.
SunScreen 3.1 Reference Manual • May 2000
■
High availability (HA) event logs are logged according to the configuration
settings for syslog.
Configuring Traffic Log Size
You can configure the size of the area used to log packet traffic, session and other
events. The log actually consists of a number of files in a particular directory. Each
Screen has a log file of its own, and you can specifically configure the size of the log
file on each Screen.
You establish the size of the log files in much the same way as other configuration
items, and these sizes are propagated to various Screens being managed during the
normal activation process. The actual resizing of the log file on a particular Screen
only occurs on the next restart of that Screen after the activation that changes the
size. This is true for primary and secondary Screens in a centralized management
group and in an HA cluster.
You should change the size of the log file when you are configuring your policies
just after installing the Screen. You must have activated the policy with the new log
sizes, but activating the policy with then new log sizes does not resize the log files.
The log file on a particular Screen is only resized when that Screen is restarted.
When the Screen is restarted, it uses the policy that was the last currently active one.
Setting the size of the log file does not cause the file system to allocate space for
storing the log immediately. Competing users of the file system on which the log file
resides should, therefore, not be allowed to consume this space. Even when the log
has filled and begins to reuse file-system space, the maximum amount of file-system
space is still not in use at all times.
Configuring the Global Default Log Size
The global default log size is controlled by the variable LogSize. It contains the
following items:
prg=log
name=LogSize
value=size (in Mbyte units)
description="descriptive text" (optional)
enabled | disabled (default is enabled)
Chapter 11
Logging
215
The global default log size can only be configured using the command line interface
(see Appendix B).
Group-Screen installations are configured on the primary Screen.
The following is an example of what you would type to display the global default
log file size, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> vars print prg=log name=LogSize
PRG="log" NAME="LogSize" ENABLED VALUE="100"
DESCRIPTION="global log capacity (MB)"...
The following is an example of what you would type to set the global default log file
size, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> vars add prg=log name=LogSize value=new size description=new
description
edit> quit
The following is an example of what you would type to set the global default log file
size to 250 Mbytes, while logged in to the primary Screen:
edit> vars add prg=log name=LogSize value=250 description="log
size (MB)"
Note – Although, the output produced by print surrounds the value of each item
in double quotes, these are only necessary on input to protect embedded spaces
within the values of items. Also, although print outputs all tag names in capital
letters (for example, PRG=), these tags are recognized in a case-insensitive manner on
input (for example, prg=, Prg=, PRG= are equivalent).
Configuring the Log Size for a Specific Screen
You configure the global log size for a centralized management group of Screens, or
Screens in an HA cluster, on the primary Screen through the administration GUI.
You configure the global log size through the command line (see Appendix B). It is
controlled by the variable LogSize.
216
SunScreen 3.1 Reference Manual • May 2000
The following is an example of what you would type to display the log file size for a
specific Screen, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> list Screen
scrn1 ADMIN_CERTIFICATE "scrn1.admin" CDP ROUTING DNS
scrn2 ADMIN_CERTIFICATE "scrn2.admin" CDP ROUTING DNS LOGSIZE 444
scrn1 does not have the log file size configured and so uses the global default
value. scrn2 has a size of 444 (Mbytes) that is used instead of the global default
value on that Screen.
The following is an example of what you would type to set the log file size for a
specific Screen, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> add Screen scrn1 ADMIN_CERTIFICATE scrn1.admin CDP ROUTING
DNS LOGSIZE 20
edit> save
edit> quit
Note – When altering the value of LogSize, be sure to reenter all the other attributes
as they were displayed by the list verb.
Configuring Events to be Logged
Logs contain three basic types of events:
■
Network traffic (packet)
■
Network session summaries
■
Extended events
Network Traffic (Packet)
You can set the action for each rule to be ALLOW, DENY, ENCRYPT, SECURE. For
each action, you can set the kind of packet logging that you want:
■
■
■
LOG_NONE – Do not log packets.
LOG_SUMMAR – Records the first 40 bytes of the packet in the log.
LOG_DETAIL – Records the complete packet in the log.
Chapter 11
Logging
217
Network Session Summaries
You can set the action to the LOG_SESSION in a rule so that it records information
about the session in the log. The information saved consists of the source and
destination addresses and ports (if applicable), the amount of data being sent in each
direction, and the length of the session. It is not used for stateless services such as ip
all. You do this using the option LOG_SESSION.
The SESSION setting does not log packet content. Each basic protocol (for example,
IP, UDP, TCP) logs statistics related to session as they complete
This option is not available for the DENY action
Extended events
In addition to logging of packets and sessions, other events are logged; these are
stored in an extended format. Such other events arise from the following logging
entities:
■
■
■
■
■
■
■
auth – Au the tic at ion logic (in various other agents)
edit – Configuration editor
fftpp – The FTP proxy
httpp – The HTTP proxy
log – The logger itself
smtpp – The SMTP proxy
telnetpp – The Telnet proxy
Each entity has a var variable to limit the severity of logged items. These variables
are named:
■
■
prg=entity name=LogSeverity—the default for all Screens.
sys=Screen prg=entity name=LogSeverity—for a specific Screen
In addition, there exist default limiters as catch-all for unnamed entities:
■
■
name=LogSeverity
sys=Screen name=LogSeverity (for all Screens or Screen-specific, respectively).
The LogSeverity variables take text strings as their value. The value functions as a
not-more-detail-than limiter and is similar to the functionality of the Solaris’ syslog
command. The text values are:
■
■
■
■
■
■
■
■
218
NONE
ALERT
CRIT
ERR
WARN
NOTE
INFO
DEBUG
SunScreen 3.1 Reference Manual • May 2000
These limiter variables operate globally (within the entities and Screens to which
their scope applies). This deals with logging situations where a particular rule is not
yet known or where no rule applies.
In addition, the effect of the per-rule DETAIL, SUMMARY, and SESSION attributes is
overridden by some of these logging entities. This override allows for finer-grained
control over events which can be attributed to a particular rule. Specifically, any
rule-specific event of a severity of INFO or greater will be logged if that rule has
(packet or session) logging enabled.
Size of Logged Items
All items in the logs have a common, 24-byte header. After this header, the following
sizes apply to logged items (by type), shown in TABLE 11-1.
TABLE 11-1
Sizes of Logged Items
Type
(packet)
SESSION
EXTENDED
Total Item Size (in bytes)
DETAIL
24 + 44 + size of packet
SUMMARY
24 + 44 + 40
ip
24 + 40
tcp
24 + 44
udp
24 + 40
24 + 64 + UTF-8 text: 0 to 4008
Level of Logging
For a given program component, you can specify the level of logging. You do this by
means of a variable setting for that component; the name of the variable is
LogSeverity. A variable that is specific to a particular Screen overrides the general
setting for that component. Beyond the variable setting for a specific component, a
Chapter 11
Logging
219
general (that is, a component that is not specific) variable controls otherwise
unlimited logging. A variable that is specific to a given Screen overrides this general
default. This search order can be summarized as:
Key Sought
--------------------------------------------------sys=Screenname prg=programname name=LogSeverity
prg=programname name=LogSeverity
sys=Screenname name=LogSeverity
name=LogSeverity
As initially configured, SunScreen contains variables defined for each program
components logging variable, along with the non-component non-Screen (global
global) default; all are initially set to the value info.
You can only configure events to be logged using the command line.
Configuring Log Event Limiters
The log limiters are controlled by LogSeverity variables as previously introduced.
Each such variable contains the following items:
■
■
■
■
■
■
sys=Screenname (optional)
prg=programname (optional)
name=LogSeverity
value=severityname (emerg,alert,...,debug)
description=descriptive text (optional)
enabled | disabled (The default is enabled.)
You can only configure the LogSeverity variables using the command line interface
(see Appendix B). You configure group-Screen installations on the primary Screen.
The following is an example of what you would type to display the
global global log limiter, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> vars print name=LogSeverity
NAME="LogSeverity" ENABLED VALUE="INFO"
DESCRIPTION="global log severity limit" ...
220
SunScreen 3.1 Reference Manual • May 2000
The following is an example of what you would type to display the global log
limiter for authentication events, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> vars print prg=auth name=LogSeverity
PRG="auth" NAME="LogSeverity" ENABLED VALUE="INFO"
DESCRIPTION="global log severity limit, authentication" ...
The following is an example of what you would type to log more (debugging)
information on a particular Screen for authentication events, while logged in to the
primary Screen:
admin% ssadm -r primary edit Initial
edit> vars add sys=Screenname prg=auth name=LogSeverity value=debug
description="debug authentication operations"
edit> quit
Note – Although, the output produced by print surrounds the value of each item
in double quotes, these are only necessary on input to protect embedded spaces
within the values of items. Also, although print outputs all tag names in capital
letters (for example, PRG=), these tags are recognized in a case-insensitive manner on
input (for example, prg=, Prg=, PRG= are equivalent). Finally, the VALUE string for
the LogSeverity variable is likewise processed in a case-insensitive manner.
Once log limiters have been altered, the configuration must be activated to
propagate the changes.
Log Retrieval and Clearing
A Screen’s log is retrieved and can be cleared using the log subcommand of ssadm.
Filtering can be applied by the Screen during retrieval, reducing the content of the
log retrieved (see the section “Log Inspection and Browsing” on page 224).
You can retrieve and postprocess logs on an automated basis (details regarding
automated log management can be found in the man page for sslogmgmt(1M).) The
maintenance command sslogmgmt(1M) automates management of SunScreen logs
for a group of centrally managed Screens. It can be run manually, as it is designed to
run as a cron(1M) job. It is available through SUNWicgSA.
Chapter 11
Logging
221
TABLE 11-2 show the thee subcommands for log.
TABLE 11-2
log Subcommands
Subcommand
Description
get
Retrieves the current content of the log, but leaves it intact.
get_and_clear
Combines these two functions, clearing the log through the point to
which it was retrieved.
clear
Makes the current content of the log inaccessible for further
retrieval operations.
Retrieval of the log produces the (binary) log records on the standard output of
ssadm. This is either redirected to a file or perhaps piped into other processes, such
as ssadm logdump for viewing, further filtering, and so forth. Manipulation of the
output stream should be performed by the shell you are using on your
administration platform.
Note – The get_and_clear operation clears the log when the Screen producing
the log finishes writing to the connection used to retrieve it. If the administration
platform crashes, the disk to which the log is being written fills, or other exceptional
conditions occur near the end of the retrieval, the clear phase can complete and some
log records can be lost.
The following is an example of what you would type to get the log from a given
(primary or secondary) Screen to store in a local file:
admin% ssadm -r Screen log get [filterargs] > local_log_file
The following is an example of what you would type to get and clear the log
atomically:
admin% ssadm -r Screen log get_and_clear [filterargs] > local_log_file
The following is an example of what you would type to simply clear the log:
admin% ssadm -r Screen log clear
The get_and_clear and clear verbs take an optional argument: a designation of
who cleared the log. This is a text string that is displayed when log statistics are
retrieved.
222
SunScreen 3.1 Reference Manual • May 2000
The following is an example of what you would type to get and clear the log, setting
this designator:
admin% ssadm -r Screen log -U "ben" get_and_clear [filterargs] > local_file
The following is an example of what you would type to simply clear the log, setting
this designator:
admin% ssadm -r Screen log -U "Ben: reset after move" clear
Log Statistics
The current statistics of a Screen’s log file can be inspected in the administration
GUI-based log browser.
These same statistics are also visible using the logstats subcommand of ssadm.
Note – You must enter the name of the Admin Interface of the Screen as listed in the
Naming Service or in the hosts file.
ssadm logstats Subcommand
The following is an example of what you would type to display the statistics for the
log on a given (primary or secondary) Screen, while logged into that Screen:
admin% ssadm -r Screen logstats
Log size (bytes): 170600
Log maximum size (bytes): 60000000
Log loss count (records): 0
Cleared at: 04/01/1999 17:43 PST
Log size details the number of bytes currently contained in the log. Log maximum
size gives the (rough) upper bound on the size of the log file (it is the configured
log file size multiplied by one million). Both of these sizes indicate only the space to
store the logged records, not the additional (though minimal) space needed to
manage those records.
Chapter 11
Logging
223
Log loss count gives the number of records that the logging server has discarded
due to the log wrapping around before being retrieved or cleared.
Cleared at gives the date and time the log was last cleared. If a text designator
(through the -U option to the log verb) was given during the operation that cleared
the log, then this line has the form:
Cleared by: ben at 04/01/1999 17:43 PST
Log Inspection and Browsing
Log mechanisms, processed through user-defined or ad hoc filters, provide the
ability to inspect previously retrieved stored logs. The results are either stored as
logs or converted to displayable text. Using the administration GUI, a Screen’s active
log file can be browsed in either a historical or live mode. You must enter the name
of the Admin Interface of the Screen as listed in the Naming Service or in the hosts
file.
Log Filters and the logdump Command
Filtering a Screen’s logs employs a common filtering mechanism and language,
regardless of the context in which it is used. These are embodied in the logdump
command. logdump is based on, and is a superset of, the snoop program, which is
provided with the standard Solaris operating environment.
logdump can be used on an Administration Station to filter and inspect logs during
active retrieval or on logs previously retrieved and stored. In conjunction with the
logmacro facility, predefined filters can be employed to simplify and regularize
routine log processing tasks.
The general usage for logdump is as a subcommand of ssadm. ssadm provides
character-set translation between strings embedded in log events and the local
character set of the Solaris system on which it runs.
Remember that although logdump is used directly as an ssadm subcommand, all
other places in SunScreen where log filtering is allowed employ the same filter
specification language. Hence, examples in this manual section should be viewed as
prototypical of these other usage contexts.
Nominally, logdump input is either a log record stream directly from a possibly
remote Screen, or captured log records from a file. This source of input is specified
by the -i option.
224
SunScreen 3.1 Reference Manual • May 2000
The following is an example of what you would type to process (piped-in) records
from the standard input:
% ssadm -r Screen log get | ssadm logdump -i- [output args] [filter args]
The following is an example of what you would type to process local file log record
input:
% ssadm logdump -i local_log_file [output args] [filter args]
logdump fundamentally outputs either a stream of log records or readable text in
various formats (after applying specified filters).
The presence of the -o option causes (binary) log records to be produced, for
example:
%ssadm logdump -i input arg -o local_log_file [filter args]
To output readable text, omit the -o option.
The formatting options for readable text are common to snoop; these are -v, -V, t[r|a|d], and -xoffset[,length].
logdump Extensions
logdump is an extension of the standard snoop packet monitoring tool provided
with the Solaris operating environment. In general, any expertise in the use of
snoop is directly applicable to use of logdump.
The facilities of logdump that are common to snoop are not detailed here; refer to
the ssadm-logdump(1m) man page.
logdump has been extended to provide for the special additional needs of the
SunScreen system. These extensions are summarized as:
■
Extensions to the format of network packets logged: inclusion of the interface on
which logged packets arrive and inclusion of the reason why packets are logged
■
Provisions for SUMMARY logging (wherein only a size-limited packet preamble
is logged)
■
Logging of network packets on routing mode (ROUTING) interfaces removes the
MAC-layer header
■
Addition of session- and extended-log events (previously described)
Chapter 11
Logging
225
■
Enforcement and synthesis of unique timestamps
■
True filter (pipeable) processing (standard snoop can process a captured packet
stream, or produce a captured packet stream, but not both—logdump allows
both)
■
Addition of filtering operators for selection of various log event types (loglvl),
event severity (logsev), logging program component (logapp), packet log
interface (logiface), and packet log reason (logwhy)
■
Addition of range operands for IP addresses and port numbers to mirror the
semantics of SunScreen address objects
■
Display of SKIP packet encapsulations
■
Display of all extensions listed above
logdump is also fundamentally different from snoop in that it is not involved in
decisions as to what SunScreen logs. (Rules and variables previously described
provide this control.) snoop is often used to filter network input during the process
of capture or direct display. logdump serves as a means to postprocess log file
content only.
SunScreen logs and snoop-captured files are not interoperable.
Logged Network Packet Enhancements
On SunScreen, the log contains network traffic that arrives on multiple link-layer
interfaces in a contemporarily interspersed manner. For this reason, it is important to
record the interface upon which the traffic was received. The interface is noted by
the name of its Solaris device (for example, le0, elx0).
Note – For snoop, the interface being monitored is specified as a command-line
option. This information is not retained in the snoop-produced capture file.
Additionally, you can configure the packet Screen to log network traffic for a variety
of reasons, such as packets that passed successfully, those that failed to match rules,
those that arrived after session state expired, and so forth. This reason is recorded as
an unsigned integer, commonly referred to as the why code. (See Appendix D, “Error
Messages” on page 319 for a complete table of these reasons.)
226
SunScreen 3.1 Reference Manual • May 2000
logdump displays these extended items and allows filtering based on these extended
items as shown in TABLE 11-3.
TABLE 11-3
Extended Items for logdump
Extended Items for
logdump
Description
logiface interface
Example of what you use to restrict, based on interface, the logiface.
It takes as its argument the name (or name prefix) of the interface
desired. The name is compared in a case-insensitive manner. For
example, to restrict log events to network traffic arriving on any qe
network device, you would type logiface qe.
logwhy #
Example of what you use to restrict based on the reason a packet
was logged. The logwhy operator takes as its argument a number
representing a reason code described above. For example, to restrict
log events to network traffic that was passed and logged, you
would type logwhy 1.
General Event Type Enhancements
In addition to network packet traffic, logs can contain session summary events and
extended log events. Each of these is represented by a different log record format.
Session summary events contain source and destination information regarding the
session (for example, IP addresses and port numbers), plus ending statistics for the
session. Extended log events are produced by various program components as
previously described. logdump displays these new event types.
logdump allows discrimination of these types from network packet traffic events.
The loglvl operator is provided to select network packet traffic, session
summaries, authentication, and application events.
Chapter 11
Logging
227
Log Record Format
TABLE 11-4 contains examples of the filters that you can use to restrict various events.
TABLE 11-4
Filters for Restriction Various events
Filter
Description
loglvl pkt
Example of what you use to restrict to network packet traffic events.
The logiface and logwhy operators imply loglvl pkt
loglvl sess
Example of what you use to restrict to session summary events. In
previous SunScreen releases, the sas_logdump program provided
-S and -s options that provided a crude form of the loglvl sess
feature. Those options are no longer supported.
loglvl auth
Example of what you use to restrict to authentication events.
loglvl app
Example of what you use to restrict to application events.
The filtering mechanisms inherited from snoop related to IP addresses (for example,
host, to, from, dst, src, and naked IP addresses and hostnames) have been
extended to filter all event types that contain corresponding IP addresses. For
example:
% ... from src host ...
matches packet, session, and extended events that originated from the given source
host.
Similarly, the filtering mechanisms inherited from snoop that are related to TCP and
UDP ports (for example, port, dstport and srcport) have been extended to filter
all event types that relate to the corresponding services. For example:
% ... port svc ...
matches packet, session, and extended events that relate to the given service.
228
SunScreen 3.1 Reference Manual • May 2000
Extended Log Event Enhancements
The extended events added to the SunScreen log contain additional fields as
previously described (severity code and program component name). The extended
log mechanism has been generalized to allow a wide variety of events to be recorded
in the log, both in SunScreen and into future releases. Because of the self-described
syntax used, virtually any event can conceivably be added to the log in this manner.
logdump allows discrimination of extended events based on their severity code. The
logsev operator provides this ability. The operand for logsev is one of the severity
pseudonyms emerg, alert, crit, err, warn, note, info, or debug. These same
designators are used to restrict the actual logging of these events. For example:
% ... logsev warn ...
matches extended events of a severity warning or greater.
logdump allows discrimination of extended events based on the name of the
program component that logged them. The logapp operator performs this
restriction. The operand for logapp is a string that is the name of a program
component. For example:
% ... logapp ftpp ...
matches extended events for the FTP proxy.
Note – The logsev and logapp operators imply a filter of ( loglvl auth or
loglvl app ).
All extended log events share some common optional attributes. These attributes are
optional because they only occur in log events where they make sense. They are
common in the sense that they are handled in a consistent way. These attributes are
shown in TABLE 11-5.
TABLE 11-5
Optional Attributes
Attribute
Description
sess_ID
A session serial number, used to recognize various events that are
related to each other
proto_ip
IP protocol number (usually 6 for TCP or UDP)
src_ip
IP source address
Chapter 11
Logging
229
TABLE 11-5
Optional Attributes (Continued)
Attribute
Description
src_port
IP source port number
dst_ip
IP destination address
dst_port
IP destination port number
reason
Short description of the event’s mission in life
msg
Generic message text:
Log Filtering Macros
For SunScreen, log filters can be defined as named quantities. These are referred to
as log macros.
Log macros are defined and stored in the registry (on the primary Screen) or they
can be defined in a local registry on any Screen. Log macros defined in the registry
of the primary Screen have the benefits of automatic propagation to secondary
Screens that are enjoyed by all other SunScreen registry objects. This propagation
affords uniform log filter availability and ease of common usage across a collection
of managed Screens.
Log macros can also be defined in a registry-like facility that is local to each
secondary Screen. This local macro capability is provided as a means to deal with
emergency situations and other issues of expediency where the process of central
macro definition and mass activation is unacceptable in the face of the conditions at
hand. As a general practice, it is a good idea to collect such local macros back into
the central registry as soon as practical for permanent storage and propagation.
Log macros are named using a global- and Screen-specific two-level scheme similar
to other objects in SunScreen. Evaluation mechanisms prefer a Screen-specific macro
with a given name over a global one. Evaluation of macros occurs at the time of
usage. (Users familiar with computer programming languages will recognize this as
a traditional delayed name binding mechanism with dynamic scoping.)
Log macros also provide a bridge between the namespace of address and service
objects defined in the SunScreen registry and their potential usage (as resolved to
values) by the filtering facilities of logdump.
Note – logdump filtering retains the hostname-to-address and service name-to-port
number mapping mechanisms of snoop, namely, DNS, NIS, host and service tables
defined for standard Solaris.
230
SunScreen 3.1 Reference Manual • May 2000
Log macros provide a way to access the name mappings of the registry in translating
names to values.
Displaying and Creating Log Macros
Log macros are actually a derivative of the general SunScreen variable mechanism.
Therefore, the variable naming and value structures exist for log macros, namely:
sys=Screen
(optional)
name=macroname
value="macrobody"
description="descriptive text"(optional)
enabled | disabled(default is enabled)
Log macros are configured in the registry using the logmacro edit subcommand of
ssadm. For group-Screen installations, they are configured on the primary Screen.
The following is an example of what you would type to display the definition of a
non-Screen specific macro, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> logmacro print name=mail-only
NAME="mail-only" ENABLED VALUE="svc smtp"
DESCRIPTION="SMTP mail" ...
The following is an example of what you would type to define a non-Screen specific
macro, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> logmacro add name=pkts-only value="loglvl pkt"
Description="only network packets"
edit> quit
The following is an example of what you would type to define a macro for a specific
Screen, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> logmacro add sys=Screenname name=SFO-routing value="port rip
src SFO-routers" description="routing activity in SFO district"
edit> quit
Chapter 11
Logging
231
Note – Although, the output produced by print surrounds the value of each item
in double quotes, these are only necessary on input to protect embedded spaces
within the values of items. Also, although print outputs all tag names in capital
letters (for example, NAME=), these tags are recognized in a case-insensitive manner
on input (for example, name=, Name=, NAME= are equivalent.)
It is also possible to create expediency log macros on any Screen. This is done using
logmacro as a subcommand of ssadm (rather than an ssadm edit subcommand).
The syntax of the rest of the usage is the same as given above.
The following is an example of what you would type to display the definition of a
non-Screen-specific macro, while logged in to the secondary Screen:
admin% ssadm -r secondary logmacro print name=mail-only
NAME="mail-only" ENABLED VALUE="svc smtp"
DESCRIPTION="SMTP mail" ...
The following is an example of what you would type to define a macro for a specific
Screen, while logged in to the secondary Screen:
admin% ssadm -r secondary logmacro add sys=secondary name=SFOrouting value="port rip src SFO-routers" description="routing
activity in SFO district"
Caution – Do not define Screen-nonspecific log macros on secondary Screens.
Log Macro Name and Body
The name of a log macro, as has been previously shown, consists of a
name=macroname part, preceded by an optional sys=Screenname Screen-restriction
part.
Unlike many objects in SunScreen, the macroname portion must be formulated as a
simple identifier, rather than a more complicated general string. (A simple identifier
begins with an ASCII alphabetic character or an underscore, followed by zero or
ASCII alphanumeric characters or underscores.)
The macrobody (value part) of a log macro consists of a filtering expression suitable
for logdump. It its simplest form, this is simply a string that can be used directly as
filtering arguments.
232
SunScreen 3.1 Reference Manual • May 2000
However, the log macro expansion feature parses the value string looking for
logdump operators that introduce address and service names and, finding same,
attempts to resolve them from the SunScreen registry. So, for addresses, it looks for
the operators host, to, from, between, dst, src and tries to resolve their operands
in the address registry. If they are found, the operator-operand sequence is rewritten
with the registry value for that address.
Similarly, for services, it looks for the operators port, dstport, and srcport. If
their operand resolves in the service registry, the operator-operand sequence is
rewritten with the registry value.
Note – In SunScreen, the registry services expanded in this manner can only consist
of TCP or UDP services. Ranges of ports are allowed but groups are disallowed, as
are services that use non-TCP non-UDP state engines.
Additionally, expansion looks for the operator macro and, if found, looks up the
operand and replaces the operator-operand sequence with the named macro’s body.
From the discussion of the processing done on the macrobody string during
evaluation, it should be evident why macro names must be simple identifiers.
Similarly, expansion cannot handle addresses or services from the registry that are
not named with simple identifiers as well.
Listing Log Macros
Log macros in the primary registry can be displayed using the logmacro
subcommand of ssadm edit. Individual macro definitions can be displayed. Also,
all Screen-non-specific definitions, or all definitions specific to a Screen, or all
definitions specific to any Screen, can be displayed. An abbreviated listing
containing just the names of these last three classes of macros can also be generated.
The following is an example of what you would type to display two specific macro
definitions, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> logmacro print name=mail-only
NAME="mail-only" ENABLED VALUE="svc smtp" DESCRIPTION="SMTP
mail"...
edit> logmacro print sys=secondary name=SFO-routing
SYS="secondary" NAME="SFO-routing" VALUE="port rip src SFOrouters" DESCRIPTION="routing activity in SFO district" ...
Chapter 11
Logging
233
The following is an example of what you would type to display all Screen-nonspecific definitions, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> logmacro print
NAME="mail-only" ENABLED VALUE="svc smtp" DESCRIPTION="SMTP mail"
...
NAME="pkts-only" ENABLED VALUE="loglvl pkt" DESCRIPTION="only
network packets" ...
The following is an example of what you would type to display all definitions
specific to a Screen, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> logmacro print sys=secondary
SYS="secondary" NAME="SFO-routing" VALUE="port rip src SFOrouters" DESCRIPTION="routing activity in SFO district" ...
The following is an example of what you would type to display all definitions
specific to any Screen, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> logmacro print sys=
SYS="primary" NAME="HQ-routing" VALUE="port rip src HQ-routers"
DESCRIPTION="routing activity in HQ district" ...
SYS="secondary" NAME="SFO-routing" VALUE="port rip src SFOrouters" DESCRIPTION="routing activity in SFO district" ...
The following is an example of what you would type to display all Screen-nonspecific names, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> logmacro names
NAME="mail-only"
NAME="pkts-only"
234
SunScreen 3.1 Reference Manual • May 2000
The following is an example of what you would type to display all names specific to
a Screen, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> logmacro names sys=secondary
SYS="secondary" NAME="SFO-routing"
The following is an example of what you would type to display all names specific to
any Screen, while logged in to the primary Screen:
admin% ssadm -r primary edit Initial
edit> logmacro names sys=
SYS="primary" NAME="HQ-routing"
SYS="secondary" NAME="SFO-routing"
The following is an example of what you would type to display two specific macro
definitions, while logged in to the secondary Screen:
admin% ssadm -r secondary logmacro print name=mail-only
NAME="mail-only" ENABLED VALUE="svc smtp" DESCRIPTION="SMTP mail"
...
admin% ssadm -r secondary logmacro print sys=secondary name=SFOrouting
SYS="secondary" NAME="SFO-routing" VALUE="port rip src SFOrouters" DESCRIPTION="routing activity in SFO district" ...
The following is an example of what you would type to display all Screen-nonspecific definitions, while logged in to the secondary Screen:
admin% ssadm -r secondary logmacro print
NAME="mail-only" ENABLED VALUE="svc smtp" DESCRIPTION="SMTP mail"
...
NAME="pkts-only" ENABLED VALUE="loglvl pkt" DESCRIPTION="only
network packets" ...
The following is an example of what you would type to display all definitions
specific to a Screen, while logged in to the secondary Screen:
admin% ssadm -r secondary logmacro print sys=secondary
SYS="secondary" NAME="SFO-routing" VALUE="port rip src SFOrouters" DESCRIPTION="routing activity in SFO district" ...
Chapter 11
Logging
235
The following is an example of what you would type to produce name lists, while
logged in to the secondary Screen:
admin% ssadm -r secondary logmacro names sys=secondary
SYS="secpndary" NAME="SFO-routing"
The following is an example of what you would type to display all Screen-nonspecific names, while logged in to the secondary Screen:
admin% ssadm -r secondary logmacro names
NAME="mail-only"
NAME="pkts-only"
The following is an example of what you would type to display all names specific to
a Screen, while logged in to the secondary Screen:
admin% ssadm -r secondary logmacro names sys=secondary
SYS="secondary" NAME="SFO-routing"
Log Macro Usage
A log macro is used by expanding its value and by causing that expansion to be
presented as a filter expression to a log get* or logdump command.
To introduce examples of log macro expansion using logmacro as a subcommand to
ssadm, the first example shows the defined values to two macros as rendered by
ssadm logmacro print:
admin% ssadm -r Screen logmacro print
NAME="probed-ports" ENABLED VALUE="icmp or dstport telnet or
dstport rlogin or dstport rsh or dstport ftp or srcport X11 or port
adminweb"
admin% ssadm -r Screen logmacro print sys=
SYS="Screen" NAME="suspicious" ENABLED VALUE="logwhy 256 logiface
le0 ( not from trusted or to hidden ) macro probed-ports"
The examples above show two macros defined. The first, probed-ports is Screennonspecific and ostensibly defines services that are thought to be targets for initial
probes leading to security attacks. The second, suspicious, is specific to Screen
and contains a more complete macro for filtering potential probes. It restricts itself
to:
236
SunScreen 3.1 Reference Manual • May 2000
■
Packets logged because no rule was found
■
Packets that had source addresses that were illegal on their interface (logwhy
256)
■
Packets arriving on a specific (presumably outside) interface (logiface le0)
■
Packets originating from untrusted hosts or targeted at hosts that are unpublished
(not from trusted or to hidden)
■
Restrictions imposed by the macro “probed-ports”.
Tip – As an aside, the verb names,flat produces a list of names that are available
for macro expansion on a particular Screen. For example, while logged in to Screen,
type:
admin% ssadm -r Screen logmacro names,flat
"probed-ports"
"suspicious"
This hides Screen-specific issues of macros and lists macro names as they are used
by embedded macro references.
Assume that the following definitions have been created and activated for registry
items:
edit> list Address
"abraham" HOST 1.2.3.4
"hidden" RANGE 129.9.9.0 129.9.9.255
"john" HOST 2.3.4.5
"martin" HOST 3.4.5.6
"trusted" GROUP { "abraham" "martin" "john" } { }
edit> list Service
"rlogin" SIMPLE FORWARD "tcp" PORT 513
"rsh" SIMPLE FORWARD "tcp" PORT 514
"telnet" SIMPLE FORWARD "tcp" PORT 23
"X11" SIMPLE FORWARD "tcp" PORT 6000-6063
Chapter 11
Logging
237
The following is an example of what you would type to expand the given macro,
while logged in to Screen:
admin% ssadm -r Screen logmacro expand suspicious
logwhy 256 logiface le0 ( not ( from 1.2.3.4 or from 2.3.4.5 or
from 3.4.5.6 ) or to 129.9.9.0..129.9.9.255 ) ( icmp or dstport 23
or dstport 513 or dstport 514 or ( srcport 20 or dstport 21 ) or
srcport 6000..6063 or port adminweb )
This usage illustrates various expansion and resolution operations performed by
expand. The clause from trusted has been replaced by the registry values for the
GROUP trusted. The clause to hidden has also been resolved to a registry
RANGE, using the logdump syntax for IP address ranges a.b.c.d..e.f.g.h.
The embedded macro reference macro probed-ports has been expanded. The
clauses that can be resolved from the registry (dstport telnet, dstport
rlogin, dstport rsh, dstport ftp, and srcport X11), have been expanded
using registry values. Clauses that were not found in the registry (icmp and port
adminweb) were left to be resolved by logdump itself. The dstport ftp clause
further illustrates some special processing employed for that protocol, and the
expansion of the srcport X11 clause shows the logdump syntax for port ranges
x..y.
Note – Resolution of SunScreen registry items performed by expand is made using
those of the currently activated policy and for the Screen whereon the expand
operation is executed.
The logmacro expand mechanism has been designed to facilitate simple
command-line usage in conjunction with the other log processing facilities of
SunScreen.
The following is an example of what you would type to employ the above macro to
retrieve the suspicious items in the current log on the Screen and display them,
while logged in to Screen:
admin% ssadm -r Screen log get ‘ssadm -r Screen logmacro expand
suspicious‘ | ssadm logdump -V -i-
238
SunScreen 3.1 Reference Manual • May 2000
APPENDIX
A
Migrating From Previous SunScreen
Firewall Products
TABLE A-1 that compares the commands used in SunScreen EFS, Release 2.0, and
SunScreen SPF-200 to the equivalent commands used in SunScreen 3.1. There are no
major changes from SunScreen EFS, Release 3.0. The old commands are obsolete in
SunScreen 3.1 and will no longer be supported.
Note – Typing the ssadm edit command invokes the configuration editor, which
displays the edit> prompt. The “add” verb is used as an example, but other verbs
such as “delete” or “list” can be used.
TABLE A-1
Command Compatibility Reference Table
Old Commands
SunScreen Equivalent
gui_install
installer
sas_logdump
ssadm logdump
sas_main
Java GUI
sas_registry
Java GUI
spf_admin_install
Installer
spf_upgrade_skip
Not used
ss_access
edit> add accessremote
edit> add accesslocal
ss_action
Not used
ss_active_config
ssadm active
ss_address
edit> add address
ss_admin_user
edit> authuser add
239
TABLE A-1
240
Command Compatibility Reference Table (Continued)
Old Commands
SunScreen Equivalent
ss_alerts
edit> add screen
ss_algorithm
ssadm algorithm
ss_authuser
edit> authuser add
ss_backup_all
ssadm backup
ss_certificate
edit> add certificate
ss_client Screen …
ssadm -r Screen …
ss_compile
ssadm activate
ss_compiler
Not used
ss_configuration
ssadm policy
ss_copy_key
Not used
ss_debug_level
ssadm debug_level
ss_default_drop
Not used
ss_defaultrouter
edit> add screen
ss_diff_config
Not used
ss_disable_send
Not used
ss_dns
edit> add screen
ss_do_compile
Not used
ss_domain
Not used
ss_editor
ssadm edit policy
ss_fix_multicast
Not used
ss_getskip
ssadm backup
ss_ha
ssadm ha
ss_ha_active_mode
ssadm ha active_mode
ss_ha_passive_mode
ssadm ha passive_mode
ss_ha_restart
Not used
ss_ha_status
ssadm ha status
ss_had
Not used
ss_init_interfaces
Not used
ss_install
ss_install
ss_interfaces
edit> add Interfaces
SunScreen 3.1 Reference Manual • May 2000
TABLE A-1
Command Compatibility Reference Table (Continued)
Old Commands
SunScreen Equivalent
ss_jar_hash
edit> jar_hash add
ss_jar_sig
edit> jar_sig add
ss_load_group
Not used
ss_log
ssadm log
ss_nat
edit> add nat
ss_network
edit> add screen
ss_patch
ssadm patch
ss_plumb_interface
Not used
ss_product
ssadm product
ss_restore_all
ssadm restore
ss_router
edit> add Interface
ss_rule
edit> add rule
ss_server
Not used
ss_service
edit> add service
ss_stateengine
edit> list stateengine
ss_sys_info
ssadm sys_info
ss_traffic_stats
ssadm traffic_stats
statetables -f
ssadm lib/statetables -f
Appendix A
Migrating From Previous SunScreen Firewall Products
241
242
SunScreen 3.1 Reference Manual • May 2000
APPENDIX
B
Command-Line Reference
This appendix describes the command line user interface for SunScreen and the
options available for each command.
The top-level programs that you run directly from a UNIX shell prompt or shell
script are available if the /opt/SUNWicg/SunScreen/bin directory is included in
your $PATH.
Other sections in this appendix describe the commands of the two major SunScreen
subsystems that interpret commands: the ssadm subcommands and the
configuration editor. There is also a section on unstable commands that are obsolete
or otherwise not guaranteed to exist in future releases of this product.
The following sections describe:
■
The command line?
■
UNIX (shell) commands
■
ssadm command
■
Unsupported commands
■
Configuration editor
■
Network monitoring and maintenance
Note – If you are familiar with the UNIX shell and SunScreen concepts and terms
the command line is appropriate. If you are new to SunScreen, use the
administration graphical user interface (GUI) to enter network settings.
243
What Is the Command Line?
All the functionality of SunScreen that is available through the administration GUI is
also available through a command. Administering your Screens through the
command line is useful if you do not want to use the browser or if you want to edit
something quickly.
You can obtain access to a Screen using the command line from its own keyboard
when the Screen is administered locally. You have superuser (root) access. You can
gain access to a Screen using the command line from an Administration Station,
when the Screen is administered remotely and requires that you use SKIP encryption
and an administration user name and password.
You maintain user-controlled data—such as common objects like address and policy
entries like rules and NAT —using the edit subcommand of ssadm.
When using the configuration editor, you must save any changes before quitting.
You invoke the configuration editor with the edit command, which is a
subcommand of ssadm, and the name of your policy, such as Initial. Once it is
running, the prompt becomes: edit>.
For a locally administered Screen, type:
# ssadm edit policy_name
For a remotely administered Screen, type:
# ssadm -r Screen_name edit policy_name
UNIX (shell) Commands
The following UNIX (shell) commands are available at your shell prompt when
/opt/SUNWicg/SunScreen/bin is included in your $PATH.
244
■
ss_install
■
ssadm
■
ss_client
SunScreen 3.1 Reference Manual • May 2000
Note – Command equivalents used for the skiptool GUI can be found in the
SunScreen SKIP 1.5.1 User’s Guide.
TABLE B-1 lists the SunScreen UNIX (shell) commands and their descriptions. Many
of these commands duplicate administration GUI functions, while others provide a
context for other commands.
TABLE B-1
Summary of Screen EFS 3.0 UNIX (shell) Commands
UNIX Command
Description
ss_install
Runs the text-based utility for creating the Initial SunScreen configuration. When combined
with pkgadd, it is equivalent to using the installation-wizard graphical user interface.
ss_client
Provides communication between an Administration Station and a Screen that is running
an earlier SunScreen firewall product release. ss_client is provided only for the purpose
of remotely administering such products using the SunScreen system as a remote
Administration Station.
ssadm
The primary command-line tool for SunScreen administration. ssadm subcommands
perform various operations such as editing and activating a SunScreen configuration, and
examining the status of a Screen.
ss_install Command
ss_install is a text-based command-line utility that runs during SunScreen
installation to create an initial configuration. ss_install, combined with pkgadd,
is the command-line equivalent to the installation-wizard graphical user interface on
the CD-ROM.
ss_install interactively queries you with various configuration options, creates a
configuration, stores it under the policy name Initial, and activates it.
After ss_install is complete, the Screen is ready to be administered using the
administration GUI or the command-line configuration editor and other tools.
ssadm Command
ssadm is the primary command-line tool for SunScreen administration. ssadm has a
number of subcommands that perform various operations such as editing and
activating a configuration, and examining the status of a Screen.
The UNIX command ssadm provides character-set translation between embedded
strings and the local character set of the Solaris system on which it runs.
Appendix B
Command-Line Reference
245
ssadm runs directly on a locally administered Screen, or indirectly from a remote
Administration Station that is using SunScreen SKIP to encrypt IP network
communications passing between them. See the SunScreen SKIP User’s Guide for
more information regarding SKIP encryption.
Usage:
ssadm [-b] [-n] subcommand [parameters...]
ssadm [-b] [-n] -r remotehost [-F ticketfile] subcommand [parameters...]
TABLE B-2 describes the options for this command.
TABLE B-2
Options for ssadm Command
Options
Description
-b
Produces binary data (instead of text) in standard input and output.
-n
Does not read any input from standard input.
-r remotehost
Provides access to a remote Screen using an address or a hostname remotehost.
-F ticketfile
Use authorization ticket stored in ticketfile.
The -b option is normally not needed because the commands that process binary
data automatically enable the binary mode. For example, ssadm backup, ssadm
restore, ssadm log, ssadm logdump, and ssadm patch handle binary data
even if -b is not specified.
The available ssadm subcommands are each described in the ssadm subcommand
section of this document.
When ssadm is executed locally on the Screen (that is, without the -r option) no
login or authentication is required, but you must be superuser to have any effect.
When ssadm is used with the -r option to access a remote Screen, login
authentication is required. You must use the ssadm login command to get a ticket
that is used by subsequent invocations of ssadm to allow access to the remote
Screen. Normally, the ticket is stored in a ticketfile, the name of which can be
specified using the -F option, or through the SSADM_TICKET_FILE environment
variable. See the ssadm login command for information about ticket files and
remote administration using ssadm.
246
SunScreen 3.1 Reference Manual • May 2000
Executing an ssadm Command From a Local Screen
You can configure a local Screen by typing the commands listed in this appendix
using the Screen’s keyboard. For example, to activate a policy Initial, you would
type:
# ssadm activate Initial
where ssadm is the command you want to execute, activate is the name of the
ssadm subcommand, and Initial is the name of the policy you want to activate.
The ssadm command resides in the /opt/SUNWicg/SunScreen/bin directory.
Include this directory in your directory search path to have access to the commands
on the local Screen.
Executing an ssadm -r Command on a Remote
Administration Station
You can configure a Screen from a remote Administration Station by preceding the
commands listed in this appendix with ssadm -r and the name of the Screen you
want to administer. For example, to activate the policy Initial on a remote Screen
called SunScreen1, you would type:
# ssadm -r SunScreen1 activate Initial
where ssadm -r indicates that you want to execute a command on a remote Screen
called SunScreen1, activate is the name of the ssadm subcommand, and
Initial is the name of the policy you want to activate.
Note – A local ssadm command can be turned into a remote ssadm command by
adding -r remote_screen_name immediately after ssadm.
When ssadm is used with the -r option to access a remote Screen, the name of the
ticketfile can be specified using the -F option, or through the
SSADM_TICKET_FILE environment.
Appendix B
Command-Line Reference
247
ssadm Subcommands
The following commands, which can be used as the subcommand argument to the
ssadm command, are described in this section.
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
activate
active
algorithm
backup
debug_level
edit
ha
lock
log
logdump
login
logout
logstats
patch
policy
product
restore
sys_info
traffic_stats
ssadm Subcommand Summary
TABLE B-3 lists the SunScreen ssadm subcommands and their descriptions. Many
ssadm subcommands duplicate the functions of the administration graphical user
interface, while others provide a context for other subcommands.
TABLE B-3
Summary of SunScreen ssadm Subcommands
ssadm Subcommand
Description
activate
Activates a Screen policy.
active
Lists information about the currently active policy.
algorithm
Lists algorithms supported by SKIP.
backup
Writes a SunScreen backup file to standard output.
debug_level
Sets or clears the level of debugging output generated by a Screen.
edit
Runs the SunScreen configuration editor. See Configuration Editor Subcommand
Summary.
248
SunScreen 3.1 Reference Manual • May 2000
TABLE B-3
Summary of SunScreen ssadm Subcommands (Continued)
ssadm Subcommand
Description
ha
Configures the features of a high availability (HA) Screen.
lock
Examines or removes the protection lock that the configuration editor places on a
policy file.
log
Maintains the Screen log file.
logdump
Filters or displays log records, as retrieved by ssadm log get.
login
Authenticates a user for administrative access through ssadm to a Screen from a
remote Administration Station.
logmacro
Expands a SunScreen logmacro object.
logout
Terminates the session created by ssadm login.
logstats
Prints information about the SunScreen log.
patch
Installs patch, as needed.
policy
Creates, deletes, lists and renames Screen policies.
product
Prints single line of descriptive SunScreen use.
restore
Reads a backup file from standard input.
sys_info
Prints a description of running SunScreen software.
traffic_stats
Reports summary information about the traffic flowing through the SunScreen,
classified by interface.
activate Subcommand
ssadm activate causes the Screen to begin “executing” a particular configuration
that is formed when the named policy is combined with the common objects. After
activation, the configuration controls the behavior of packet filtering, encryption and
decryption, proxies, logging, and administrative access.
Syntax:
ssadm activate [-n] [-l] policy
Appendix B
Command-Line Reference
249
TABLE B-4 describes the options for this command.
TABLE B-4
Options for activate Subcommand
Options
Description
-n
Does not actually make the configuration active, just verifies that it
is valid.
-l
Does not send the configuration to other Screens in the centralized
management group, only activates it on the local Screen.
The named policy is combined with the common objects to form a configuration.
Note – If you omit the policy argument, ssadm activate reads a configuration file
from standard input. Since the format of a configuration file is undocumented and
private to the SunScreen internal software, using ssadm activate in this way is
not supported.
active Subcommand
ssadm active prints out a description of the configuration that is currently being
executed by the Screen. When run with the -x option, the actual configuration file is
extracted from the running system and can be saved for later examination.
Usage:
ssadm active
ssadm active -x policy
Without the -x option, ssadm active describes the active configuration with two
lines of text. The first line lists the name of the Screen on which the configuration
was originally stored, the name of the internal database in which it was stored (this
name is always default), and the name of the policy, including its version number.
The second line lists the date and time when the configuration was activated, and
the user (either a UNIX user or SunScreen administration authorized user) who
caused it to be activated.
For example:
# ssadm active
Active configuration: greatwall default Initial.3
Activated by admin on 03/09/1999 02:58:36 PM PST
250
SunScreen 3.1 Reference Manual • May 2000
In this example, the Screen is currently running a configuration that came from the
Screen named greatwall (which might be the current Screen or, if the Screen is a
member of a centralized management group, the primary Screen of the centralized
administration group). The configuration includes version 3 of the policy Initial.
With the -x option, ssadm active saves the active configuration into the named
policy that can be examined using the edit command. The named policy must not
already exist; ssadm active creates the policy. The saved policy contains a full set
of common objects in addition to the policy rules. The -x option is different from a
normal policy that contains only policy rules and is meant to be combined with the
currently defined common objects.
Note – If the -x option is specified and the policy argument is omitted, ssadm
active writes a configuration file to standard output. Since the format of a
configuration file is undocumented and private to the SunScreen internal software,
using ssadm active in this way is not supported.
algorithm Subcommand
ssadm algorithm lists the SKIP algorithms that are available for a specified
algorithm type.
Usage:
ssadm algorithm type [skipversion]
where type must be one of “key”, “data”, “mac”, or “compression”. skipversion, if
supplied, must be either “SKIP_VERSION_1” or “SKIP_VERSION_2”.
backup Subcommand
ssadm backup writes a Screen backup file to standard output.
Usage:
ssadm backup [-v] > file
The backup file contains the complete configuration of SKIP, plus all currently
defined common objects, policies, and, if the -v option is specified, all of the saved
versions of the policies.
The backup file can be restored at a later time using the ssadm restore command.
Appendix B
Command-Line Reference
251
Caution – SECURITY WARNING. The file created by ssadm backup contains
sensitive information (SKIP secret keys) that must be stored and disposed of
appropriately to protect the integrity of the Screen.
debug_level Subcommand
ssadm debug_level controls the output of internal debugging information from
the SunScreen kernel.
Usage:
ssadm debug_level [newlevel]
ssadm debug_level ?
With no arguments, ssadm debug_level prints out the current debug level in
hexadecimal. With the newlevel argument, ssadm debug_level sets the debug
level to newlevel. With the question mark argument (may need to be quoted in the
UNIX shell) ssadm debug_level prints out a list of bit values and their
meanings.
The debugging information, when enabled, is written through the kernel message
mechanism and typically ends up on the system console or the kernel message logs.
The format of the messages is not documented and is only used by Sun support
personnel.
edit Subcommand
ssadm edit runs the SunScreen configuration editor.
Usage:
ssadm edit policy
ssadm edit policy < file
ssadm edit policy -c commandstring
See the “Configuration Editor subcommand” section for information regarding
commands supported by ssadm edit. The configuration editor can be used in any
of three modes: interactive, batch, or “-c” mode. In interactive mode, the editor
prints a prompt (edit>) before each command is read from your terminal. In batch
mode, the editor silently reads commands from standard input. Commands are read
until the editor receives end-of-file or a quit command.
252
SunScreen 3.1 Reference Manual • May 2000
If ssadm edit is run on an interactive terminal and its input and output are not
redirected; it automatically enters interactive mode. If standard input is a pipe or a
file, the configuration editor runs in batch mode.
If ssadm edit is run with the -c option, it executes the commandstring and then
exits without reading any other commands. commandstring must be a single
argument to the program, so in the UNIX shell it usually has to be quoted with
single or double quotes.
ha Subcommand
ssadm ha performs operations on a Screen in a high availability (HA) cluster.
Usage:
ssadm ha function parameters...
TABLE B-5 describes the function parameters for this command.
TABLE B-5
Function Parameters for ha Subcommand
Functions
Descriptions
status
Displays status of the HA cluster.
active_mode
Puts the Screen in active mode.
passive_mode
Puts the Screen in passive mode.
init_primary interface
Turns a standalone (non-HA) Screen into an HA primary Screen,
thereby creating a new HA cluster containing one Screen. interface
is the interface to be used for the HA heartbeat and synchronization.
primaryIP is the IP address (on the HA network) of the primary
machine in the cluster.
init_secondary interface primaryIP
Turns a standalone (non-HA) Screen into an HA secondary screen
ready to join an existing HA cluster. Where interface is used for the
HA heartbeat and synchronization, and primaryIP is the IP address
(on the HA network) of the primary machine in the cluster.
add_secondary secondaryIP
Adds an initialized HA secondary Screen (see init_secondary
above) into an existing HA cluster. This command is executed on the
primary Screen in the HA cluster. secondaryIP is the IP address (on the
HA network) of the secondary machine to be added.
lock Subcommand
ssadm lock manipulates the lock that protects a policy from simultaneous
modification by multiple administrators.
Appendix B
Command-Line Reference
253
Usage:
ssadm lock -w policy
ssadm lock -c policy
ssadm lock -w prints a line of text describing the status of the lock.
ssadm lock -c forcibly breaks the lock and attempts to terminate (with a SIGHUP
signal) the previous holder of the lock.
For example:
# ssadm lock -w Initial
Lock held by [email protected] process id:8977
# ssadm lock -c Initial
# ssadm lock -w Initial
Lock available
log Subcommand
ssadm log retrieves and clears the SunScreen log.
Usage:
ssadm log get filter_args...
ssadm log get_and_clear filter_args...
ssadm log clear
logdump Subcommand
ssadm logdump is used to filter or display log records, as retrieved by
ssadm log get.
Usage:
ssadm logdump parameters...
login Subcommand
ssadm login authenticates a user for administrative access through ssadm to a
Screen from a remote Administration Station.
254
SunScreen 3.1 Reference Manual • May 2000
Usage:
ssadm -r remotehost login username password
ssadm login creates a session on the remote Screen and provides a ticket that
allows subsequent invocations of the ssadm command to access the remote Screen
without using a password.
ssadm login is only available with the -r remotehost option.
The ticket is written to standard output. If a ticketfile is specified using the -F option
to ssadm or the SSADM_TICKET_FILE environment variable, then ssadm login
automatically stores the ticket in ticketfile in addition to writing it to standard output.
For example:
# SSADM_TICKET_FILE=$HOME/.ssadmticket
# export SSADM_TICKET_FILE
# touch $SSADM_TICKET_FILE
# chmod go= $SSADM_TICKET_FILE
# ssadm -r greatwall login admin password
WRITE access <E23B344150C702EC>
# ssadm -r greatwall activate Initial
Configuration activated successfully on greatwall.
# ssadm -r greatwall active
Active configuration: greatwall default Initial.3
Activated by admin on 03/09/1999 02:58:36 PM PST
# ssadm -r greatwall logout
The above example is for sh or ksh; other shells may require different commands.
ssadm login is only available with the -r remotehost option.
When using the ssadm login command on multiuser Administration Stations, any
other user can snoop the admin user and password using ps, then (because SKIP is
enabled from that host) access the Screen as that user.
Do not have a general-use Solaris system act as a remote Administration Station.
Additionally, never use the ssadm login command on a Solaris system while other
users are logged in
Caution – Screen administration is discouraged from non-Solaris platforms. Serious
security holes with other operating systems can readily be exploited to compromise
the network security infrastructure.
See the ssadm-login(1M) man page for more information on the login
command.
Appendix B
Command-Line Reference
255
logout Subcommand
ssadm logout terminates the session created by ssadm login.
Usage:
ssadm -r remotehost logout
ssadm logout is only available with the -r remotehost option.
logmacro Subcommand
ssadm logmacro expands a SunScreen logmacro object.
Usage:
ssadm logmacro expand macroname
logmacro add macrokey macrovalue
logmacro delete macrokey
logmacro print[,sortopt] [ macrokey ]
logmacro names[,sortopt]
where macrokey is of the form [ SYS=scrnname ] NAME=name
macrovalue is of the form VALUE=macrobody
sortopt is one of asc, desc, iasc
(For example, desc specifies a plaintext description string desc to be associated
with the object.
logstats Subcommand
ssadm logstats prints information about the SunScreen log.
Usage:
ssadm logstats
patch Subcommand
ssadm patch installs a patch, as needed.
256
SunScreen 3.1 Reference Manual • May 2000
Usage:
For stealth-mode Screens from Remote Administration Stations, use:
ssadm [-r screen_name] patch Install [NOREBOOT] < patch.tar.Z
ssadm [-r screen_name] patch Backout [NOREBOOT] patchID
On routing-mode Screens, the standard Solaris patchadd and patchrm commands
can be used.
If a SunScreen software patch is needed, detailed instructions are provided with the
patch.
policy Subcommand
ssadm policy creates, deletes, renames, or lists the defined policies.
Usage:
ssadm policy -a policies...
ssadm policy -c oldname newname
ssadm policy -d [-v] policies...
ssadm policy -l [-v] [policies...]
ssadm policy -r oldname newname
TABLE B-6 describes the options for this command.
TABLE B-6
Options for policy Subcommand
Options
Description
-a
Creates policies with the specified names. The newly created policies contain no rules and
references the currently defined common objects.
-c
Creates a policy named newname as a copy of the existing policy named oldname.
-d
Deletes the named policies. The specified policies can be either generic policy names, such as
Initial, or specific versions, such as “Initial.3”. When a generic policy name is specified
and the -v option is specified, ssadm policy -d deletes all of the versions of the policy. When
a specific version is specified, only that version is deleted.
-l
Lists the named policies (or all policies available if no policies are given). The -v option also lists all
of the saved versions of the policies.
-r
Renames the existing policy oldname to newname.
Appendix B
Command-Line Reference
257
product Subcommand
ssadm product prints out a single line of text describing the SunScreen product in
use.
Usage:
ssadm product
restore Subcommand
ssadm restore reads a backup file from standard input. The backup file must
have been created using the backup command.
Usage:
ssadm restore < file
spf2efs Subcommand
ssadm spf2efs converts a set of configuration data saved from a SunScreen
SPF-2000 Screen into SunScreen format.
Usage:
ssadm spf2efs < file
sys_info Subcommand
ssadm sys_info prints a description of the running SunScreen software.
Usage:
ssadm sys_info
For example:
# ssadm sys_info
Product:
System Boot Time:
SunScreen Boot Time:
Version:
258
SunScreen 3.1 Reference Manual • May 2000
SunScreen
03/15/1999 03:51 PST
Mon Mar 13 03:51:56 PST 200
Release 3.1, March 10
2000(v0310991418)
traffic_stats Subcommand
ssadm traffic_stats reports summary information about the traffic flowing
through the Screen, classified by interface.
Usage:
ssadm traffic_stats [interfaces...]
Unsupported Commands
Commands listed in this section are only used for abnormal maintenance or
customer support functions, or as a temporary work around to limitations of the
current software.
These commands are “unstable,” which means that they may not be provided in
future SunScreen product releases, or in versions for other operating systems.
ssadm lib/screeninfo Command
ssadm lib/statetables -f Command
ssadm lib/support Command
ssadm SKIP Commands
ssadm lib/screeninfo Command
ssadm lib/screeninfo runs in sequence several of the functions of the ssadm
lib/support command, printing out a large set of information about the Screen
and its current configuration.
Usage:
ssadm lib/screeninfo
The output of this command can be redirected to a file and may be requested by
Sun’s Support services if you encounter problems with your Screen.
Appendix B
Command-Line Reference
259
ssadm lib/statetables -f Command
ssadm lib/statetables -f causes the Screen to flush (discard) all of its
connection state information. This causes all previously active connections through
the Screen to be effectively disconnected.
This command is often useful after activating a modified policy that disallows some
traffic that was previously allowed. Without running
ssadm lib/statetables -f, you allow any previously existing connections to
remain active even if the new policy does not allow them. By running
ssadm lib/statetables -f, you cause all previously existing connections to be
disconnected and the active policy will apply to any subsequent connections.
ssadm lib/support Command
ssadm lib/support provides various diagnostic and status information that can
be useful when requesting customer support for the SunScreen product.
Usage:
ssadm lib/support function parameters...
This information may be requested by Enterprise Services if you encounter problems
with your Screen.
Note – If you have any support issues, call your authorized service provider. For
further information about support, use the following URL to contact Sun’s Support
services: http://www.sun.com/service/support/index.html.
The major functions are shown in TABLE B-7
TABLE B-7
260
Support Command Functions
Functions
Description
config
Bring over configuration files for the active policy
date
Set and get current time/date
(SET DATE WITH CAUTION!)
disks
Check disk space (df -k)
eeprom
Check eeprom settings
findcore
Check if a core file exists
help
Prints a listing of functions available for this command
SunScreen 3.1 Reference Manual • May 2000
TABLE B-7
Support Command Functions (Continued)
Functions
Description
last
Check boot history (last)
packages
Check pkginfo and patch history
procs
Check processes (ps -elf)
skip
Check contents of /etc/skip/ directory
stats
Check the kernel networking statistics (netstat -k)
streams
Check the STREAMS statistics (netstat -m)
versions
Bring over version information on major SunScreen components
ss_client Command
ss_client is equivalent to the command of the same name provided with earlier
SunScreen firewall products, such as SunScreen EFS, Release 2.0, or
SunScreen SPF-200. ss_client is provided only for the purpose of remotely
administering such products using the SunScreen system as a remote Administration
Station.
Usage: ss_client hostname command
For information on how to use ss_client to administer an earlier SunScreen
firewall product, see the documentation for that product.
ssadm SKIP Commands
ssadm lib/skipca
ssadm lib/skipd_restart
ssadm lib/skipdb
ssadm lib/skiplocal
ssadm lib/skipstat
Appendix B
Command-Line Reference
261
These commands provide access to the command-line administration tools of the
SunScreen SKIP software. They are primarily useful when a Screen is not physically
accessible or does not allow logins over the network and you want to configure SKIP
using the ssadm command with the -r option from a remote Administration
Station.
See the corresponding commands in the SunScreen SKIP 1.5.1 User’s Guide for
information on the parameters.
Configuration Editor
The configuration editor is the primary command-line tool for creating and
manipulating the objects that control the operation of a Screen.
Configuration Editor Data Model
TABLE B-8 lists the data types that compose the Data Model as maintained by the
configuration editor (ssadm edit) and the ssadm policy command.
TABLE B-8
Configuration Editor Object Type Name Summary
Object Type Name
Storage
Access
Method
Description
address
common
named
Describe addresses of network elements
screen
common
named
Describe Screen objects and their relationships
state engine
common
(read only)
named
Describe filtering capabilities of packet filter engine.
service
common
named
Define network services that can be filtered
interface
common
named
Describe network interfaces of a Screen.
certificate
common
named
Refer to certificate used for SKIP connections
time
common
named
Define time intervals for time-dependent rules
authuser
external
named
Describe users for administration and/or proxy
access
proxyuser
external
named
Describe users for proxy access
jar_hash
external
named
Describe Java archive hash (for HTTP proxy applet
filtering)
jar_sig
external
named
Describe Java archive signature (for HTTP proxy
applet filtering)
262
SunScreen 3.1 Reference Manual • May 2000
TABLE B-8
Configuration Editor Object Type Name Summary (Continued)
Object Type Name
Storage
Access
Method
Description
logmacro
external
named
Define macro files
mail_relay
external
named
Describe mail relays (for SMTP proxy mail filtering)
mail_spam
external
named
Describe spam domains (for SMTP proxy mail
filtering)
policy
policy list
named
Provide multiple, named polices for storing different
configurations
filter rule
policy
ordered
Describe network traffic flow policy
nat rule
policy
ordered
Describe NAT translations
local access rule
policy
ordered
Describe who can access the Screen for local
administration and what they can do.
remote access rule
policy
ordered
Describe who can access the Screen for remote
administration and what they can do.
VPN gateway
policy
ordered
Describe how VPN hosts are protected behind
certificates and tunnels
VPN
policy
ordered
Virtual object representing a collection of VPN
gateways
Object types marked as having common storage in the table are normally stored in
the common objects registry that is not part of any particular policy. These objects
are used by all policies, so changes to the common objects can affect the behavior of
multiple policies. To edit the common objects, it is necessary to specify a policy name
when starting the configuration editor even if you are not modifying any policy
objects.
Object types marked as having policy storage in the table are stored as part of a
policy. Policy objects often refer to common objects and, therefore, can have different
meaning depending on the value of common objects. For example, a policy can
contain a rule object that allows address A to communicate with address B. The
address objects A and B are defined in the common objects.
Object types marked as having external storage in the table are almost equivalent to
common objects, but they are stored in a separate database that is not affected by the
quit, reload, or save commands. Changes to these objects are always immediate,
and persist even if the save command is not used.
Object types marked as having policy list storage in the table represents the names
of the policies themselves. Minimal capabilities are provided by the configuration
editor to manage the policy. A policy currently being edited can be saved or cloned
(or portions of it) into a new policy. Other policy requests, such as add, delete, and
rename are provided by the ssadm policy command.
Appendix B
Command-Line Reference
263
Configuration Editor Commands
The ssadm edit commands are used when running the configuration editor, which
is responsible for maintaining the SunScreen configuration database.
TABLE B-9 lists the SunScreen configuration editor ssadm edit subcommands and
their descriptions. Many subcommands duplicate administration GUI functions,
while others provide a context for other subcommands.
TABLE B-9
264
SunScreen Configuration Editor ssadm edit Subcommand Summary
edit Subcommand
Description
add
Create or redefine an entry.
add_member
Add member to an Address, Certificate, or Service group.
authuser
Manipulate the list of authorized users.
del[ete]
Delete the specified entry of the given TYPE.
del[ete]_member
Delete member from an Address, Certificate, or Service group.
insert
Insert a new object of one of the ordered (indexed) types in a
specified position in the corresponding list.
jar_hash
Manipulate the list of JAR hashes used by the HTTP proxy.
jar_sig
Manipulate the list of JAR signatures used by the HTTP proxy.
list
Display all data for all entries or a specific entry of a given TYPE.
list_name
Display the set of unique basenames and subtype of all of a given
TYPE.
load
Load a policy into the configuration editor.
lock
Lock the Registry and policy in anticipation of performing edits.
lock_status
Return the status of the lock relative to this editor.
mail_relay
Manipulate the list of mail relays used by the SMTP proxy.
mail_spam
Manipulate the list of spam domains used by the SMTP proxy.
move
Move an indexed entry from its current location in the ordered list
to the new location.
proxyuser
Manipulate the list of proxy users.
refer
Determine if a named object of a given TYPE is referred to in the
Registry or the current policy.
referlist
Display a list of all entries in the Registry or the current policy that
refer to a specified named-object of a given TYPE.
reload
Discard any and all edits, if made, and reload the data into the
editor from the database.
SunScreen 3.1 Reference Manual • May 2000
TABLE B-9
SunScreen Configuration Editor ssadm edit Subcommand Summary
edit Subcommand
Description
rename
Rename a specified named-object of a given TYPE.
renamereference
Rename all references to a specified named-object of a given TYPE.
replace
Replace an object at a specified index.
save
Save all current edits to the Registry and policy.
saveas
Saves the data currently in the editor under new name.
search
Search the Registry for objects that match specified criteria.
vars
Manipulates variables used for RADIUS configuration.
verify
Takes no arguments and verifies the currently loaded policy.
quit
Cause the editor to terminate if there are no unsaved changes.
QUIT
Cause the editor to terminate even if there are unsaved changes.
In the following command descriptions, when the name of an object of a particular
TYPE is required, it is indicated by name_TYPE. If an index is needed, it is indicated
by #. A keyword that was required in previous SunScreen releases but is now
optional, is indicated by KEYWORD.
add Subcommand
Creates or redefines an entry.
Usage:
add TYPE parameters...
If a named-type is specified and an entry with that name already exists, it is replaced
with the new entry. If it does not exist, one is created with the new name. All of the
following have a similar request of add_nocheck, which does not perform
consistency checking.
add address Subcommand
add address "name_ADDRESS" <HOST> #.#.#.#
add address "name_ADDRESS" <RANGE> #.#.#.# #.#.#.#
add address "name_ADDRESS" <GROUP> { "name_ADDRESS" ... }
{ "name_ADDRESS" ... }
Appendix B
Command-Line Reference
265
The following fields are optional and can be specified in any order after the address
keyword:
SCREEN "name_SCREEN"
COMMENT "comment string"
Note – The addresses * and localhost are reserved and cannot be edited.
add screen Subcommand
add screen "name_SCREEN"
The following fields are optional and can be specified in any order after the screen
keyword:
MASTER "name_SCREEN"
HA_PRIMARY
HA_SECONDARY
TIMEOUT #
SNMP #.#.#.# ... (list can be empty; not output if empty list)
SNMP_TIMER # (if SNMP is set)
CDP {"on" if present, "off" otherwise}
RIP {"on" if present, "off" otherwise}
DNS {"on" if present, "off" otherwise}
NIS {"on" if present, "off" otherwise}
LOGSIZE # {default is 100 MBytes if not present}
STEALTH_NET #.#.#.# #.#.#.# {Network and Netmask for stealth type
Interfaces}
HA_IP #.#.#.# (required if HA_PRIMARY is set)
HA_ETHER xx:xx:xx:xx:xx:xx (required if HA_PRIMARY is set)
COMMENT "comment string"
266
SunScreen 3.1 Reference Manual • May 2000
If the Screen is to be a part of an HA cluster, and administered remotely, then the
following fields must be specified as well. They can be specified in any order after
the screen keyword:
ADMIN_IP #.#.#.# or name_ADDRESS
ADMIN_CERTIFICATE "name_CERTIFICATE"
KEY "name_KEY_ALGORITHM"
DATA "name_DATA_ALGORITHM"
MAC "name_MAC_ALGORITHM"
COMPRESSION "name_COMPRESSION_ALGORITHM"
TUNNEL "name_ADDRESS"
The screen * is reserved and cannot be edited.
add service Subcommand
add service "name_SERVICE" <SINGLE> filter ...
add service "name_SERVICE" GROUP "name_SERVICE" ...
For SINGLE services, a list of Filters follows the SINGLE keyword. The list must not
be empty. Each Discriminator list also must not be empty. A Filter is of the form:
FORWARD "name_STATEENGINE" discriminator ...
REVERSE "name_STATEENGINE" discriminator ...
An individual discriminator is as follows:
PORT #
PORT #-# (Note, no space is allowed before or after the - character)
BROADCAST #
BROADCAST #-#
An optional parameter for discriminators, which appears immediately after the
number or range it modifies, is:
PARAMETERS space-separated list of #
For GROUP services, a space-separated list of "name_SERVICE" entries follows the
GROUP keyword.
Appendix B
Command-Line Reference
267
The following fields are optional and can be specified in any order after the service
keyword:
SCREEN "name_SCREEN"
COMMENT “comment string”
add interface Subcommand
add interface "name_INTERFACE" type "name_ADDRESS"
type must be one of ADMIN, DISABLED, ROUTING, HA, or STEALTH.
The following fields are optional for stealth interface types and can be specified in
any order after the interface keyword. Up to 5 ROUTERs per stealth interface can
be specified. More can be specified, but only 5 (no guarantee in which order) are
used by the system.
ROUTER #.#.#.#
The following fields are optional for all interface types and can be specified in any
order after the “interface” keyword:
SCREEN "name_SCREEN"
COMMENT "comment string"
The following fields are optional for all interface types except DISABLED and can be
specified in any order after the interface keyword.
LOG NONE {default if no LOG is specified}
LOG SUMMARY LOG DETAILED
ICMP NONE
ICMP NET_UNREACHABLE
ICMP HOST_UNREACHABLE
ICMP PORT_UNREACHABLE
ICMP NET_FORBIDDEN
ICMP HOST_FORBIDDEN
SNMP {"on" if present, "off" otherwise}
268
SunScreen 3.1 Reference Manual • May 2000
add certificate Subcommand
add certificate "name_CERTIFICATE" SINGLE NSID # MKID "#"
add certificate "name_CERTIFICATE" GROUP "name_CERTIFICATE" ...
For GROUP certificates, a space-separated list of name_CERTIFICATE entries follows
the GROUP keyword.
The following fields are optional for SINGLE entries and may be specified in any
order after the certificate keyword:
G #
P #
KEY_LENGTH #
LOCAL "name_SCREEN"
The following fields are optional and can be specified in any order after the
“certificate” keyword:
SCREEN "name_SCREEN"
COMMENT "comment string"
add time Subcommand
add time "name_TIME"
The following fields are optional and can be specified in any order after the time
keyword:
EVERYDAY
SUNDAY
MONDAY
TUESDAY
WEDNESDAY
THURSDAY
FRIDAY
SATURDAY
SCREEN "name_SCREEN"
Appendix B
Command-Line Reference
269
COMMENT "comment string"
The time object * cannot be modified.
Following any of the *DAY keywords can be a time of day specification in the form
{timespec ...} . timespec is a time range in the form:
Start Hour:Start Minute Stop Hour:Stop Minute
Examples are: { 1:00 2:30 } and { 1:00 2:30 4:00 6:00 }. Twenty-four–hour time format
is used, so the valid times are 0:00 (starting at midnight) through 24:00 (ending at
midnight).
add rule Subcommand
add rule "name_SERVICE" name_ADDRESS
Appends the rule to the end of the list of rules in the policy. insert rule should
be used to position a new rule into an existing policy.
The following fields are optional and can be specified in any order after the rule
keyword:
ALLOW {default if no ACTION specified}
DENY
LOG NONE {also LOG_NONE, default if no LOG is specified}
LOG SUMMARY {also LOG_SUMMARY}
LOG DETAILED {also LOG_DETAILED}
LOG SESSION {also LOG_SESSION, only valid for ALLOW rules, will be error for
DENY}
SNMP {"on" if present, "off" otherwise}
USER "name_USER" {only used if PROXY_FTP or PROXY_Telnet set below }
TIME "name_TIME"
SCREEN "name_SCREEN"
COMMENT “comment string"
The following combo-field is optional and only valid in a rule that has ALLOW
specified. It can be specified anywhere after the rule keyword:
SKIP_VERSION_1 "name_CERTIFICATE" "name_CERTIFICATE"
"name_KEY_ALGORITHM" "name_DATA_ALGORITHM”
270
SunScreen 3.1 Reference Manual • May 2000
SKIP_VERSION_2 "name_CERTIFICATE" "name_CERTIFICATE"
"name_KEY_ALGORITHM" "name_DATA_ALGORITHM"
"name_MAC_ALGORITHM" "name_COMPRESSION_ALGORITHM”
The following fields are optional and only valid within a SKIP_VERSION_1 or
SKIP_VERSION_2 combo-field. They can be specified in any order after the
SKIP_VERSION_# keyword:
SOURCE_TUNNEL "name_ADDRESS”
DESTINATION_TUNNEL "name_ADDRESS"
The following field is optional and only valid in a rule that has DENY specified. It
can be specified anywhere after the rule keyword:
ICMP NONE {also ICMP_NONE, default if nothing is specified}
ICMP NET_UNREACHABLE {also ICMP_NET_UNREACHABLE}
ICMP HOST_UNREACHABLE {also ICMP_HOST_UNREACHABLE}
ICMP PORT_UNREACHABLE {also ICMP_PORT_UNREACHABLE}
ICMP NET_FORBIDDEN {also ICMP_NET_FORBIDDEN}
ICMP HOST_FORBIDDEN {also ICMP_HOST_FORBIDDEN}
The following field is optional and only valid in a rule that has ALLOW specified
and NO SKIP information. It can be specified anywhere after the rule keyword:
VPN "name_VPN"
The following fields are optional and only valid in a rule that has not specified any
SKIP information and no VPN. They can be specified anywhere after the rule
keyword. Only one of them can be specified in a given rule.
PROXY_FTP
PROXY_HTTP
PROXY_SMTP
PROXY_Telnet
The following fields are optional and only valid in a rule that has specified
PROXY_FTP. They can be specified anywhere after the PROXY_FTP keyword:
FTP_GET
NO_FTP_GET {default if FTP_GET not specified}
FTP_PUT
Appendix B
Command-Line Reference
271
NO_FTP_PUT (default if FTP_PUT not specified}
FTP_CHDIR
NO_FTP_CHDIR {default if FTP_CHDIR not specified}
FTP_MKDIR
NO_FTP_MKDIR {default if FTP_MKDIR not specified}
FTP_RENAME
NO_FTP_RENAME {default if FTP_RENAME not specified}
FTP_REMOVE_DIR
NO_FTP_REMOVE_DIR {default if FTP_REMOVE_DIR not specified}
FTP_DELETE
NO_FTP_DELETE {default if FTP_DELETE not specified}
The following fields are optional and only valid in a rule that has specified
PROXY_HTTP. They can be specified anywhere after the PROXY_HTTP keyword:
COOKIES
NO_COOKIES {default if COOKIES not specified}
ACTIVE_X
NO_ACTIVE_X {default if ACTIVE_X not specified}
SSL
NO_SSL {default if SSL not specified}
JAVA_SIGNATURE
JAVA_HASH
JAVA_SIGNATURE_HASH
JAVA
NO_JAVA {default if no other JAVA setting is specified}
The following fields are optional and only valid in a rule that has specified
PROXY_SMTP. They can be specified anywhere after the PROXY_SMTP keyword:
RELAY
NO_RELAY {default if RELAY not specified}
272
SunScreen 3.1 Reference Manual • May 2000
add nat Subcommand
add nat STATIC "name_ADDRESS" "name_ADDRESS" "name_ADDRESS"
“name_ADDRESS”
add nat DYNAMIC "name_ADDRESS” "name_ADDRESS" "name_ADDRESS”
"name_ADDRESS"
The following fields are optional and can be specified in any order after the nat
keyword:
SCREEN "name_SCREEN"
COMMENT "comment string"
add accesslocal Subcommand
add accesslocal USER “name_USER”
The following fields are optional and can be specified in any order after the
accesslocal keyword:
SCREEN "name_SCREEN"
COMMENT "comment string"
add accessremote Subcommand
add accessremote USER "name_USER" "name_ADDRESS" SKIP_VERSION_1
"name_CERTIFICATE" "name_KEY_ALGORITHM" "name_DATA_ALGORITHM"
add accessremote USER "name_USER" "name_ADDRESS" SKIP_VERSION_2
"name_CERTIFICATE" "name_KEY_ALGORITHM" "name_DATA_ALGORITHM"
"name_MAC_ALGORITHM" "name_COMPRESSION_ALGORITHM"
The following field is optional for accessremote entries. It can be specified in any
order after the accessremote keyword:
TUNNEL "name_ADDRESS" { if the remote machine is using tunneling }
The following fields are optional and can be specified in any order after the
accesslocal/accessremote keyword:
PERMISSION ALL
PERMISSION WRITE
Appendix B
Command-Line Reference
273
PERMISSION READ
PERMISSION STATUS
PERMISSION NONE { default if no PERMISSION is specified }
SCREEN "name_SCREEN"
COMMENT "comment string"
add vpngateway Subcommand
add vpngateway "name_VPN" "name_ADDRESS” SKIP "name_CERTIFICATE"
The following fields are required and can be specified in any order after the
vpngateway keyword:
KEY "name_KEY_ALGORITHM"
DATA "name_DATA_ALGORITHM"
MAC "name_MAC_ALGORITHM"
COMPRESSION “name_COMPRESSION_ALGORITHM”
The following fields are optional and can be specified in any order after the
"vpngateway" keyword:
TUNNEL "name_ADDRESS"
COMMENT "comment string"
add_member Subcommand
Adds a member to a group or list.
Usage:
add_member address "name_ADDRESS" "name_ADDRESS"* { add to include
list }
add_member address "name_ADDRESS" EXCLUDE "name_ADDRESS"* { add
to exclude list }
add_member service "name_SERVICE" "name_SERVICE"*
add_member certificate "name_CERTIFICATE" "name_CERTIFICATE"*
274
SunScreen 3.1 Reference Manual • May 2000
Note – * denotes that multiple space-separated names can be specified in a single
request.
The following field may be necessary to uniquely identify an entry. If so, it can be
specified after the TYPE keyword:
SCREEN "name_SCREEN"
authuser Subcommand
Manipulates the list of authorized users.
Usage:
authuser add name parameters...
authuser delete name
authuser print
delete Subcommand
Deletes the specified entry of the given TYPE.
Usage:
del[ete] address "name_ADDRESS"
*del[ete] screen "name_SUNSCREEN"
del[ete] service "name_SERVICE"
del[ete] interface "name_INTERFACE"
del[ete] certificate "name_CERTIFICATE"
del[ete] time "name_TIME"
*del[ete] rule #
*del[ete] nat #
*del[ete] accesslocal #
*del[ete] accessremote #
*del[ete] vpngateway #
Appendix B
Command-Line Reference
275
The following field may be necessary to uniquely identify an entry. If so it can be
specified after the TYPE keyword, except for the entries preceded by an * above:
SCREEN “name_SCREEN”
delete_member Subcommand
Deletes a member from a group or list.
Usage:
del[ete]_member address "name_ADDRESS" "name_ADDRESS"* { from
include list }
del[ete]_member address “name_ADDRESS" EXCLUDE "name_ADDRESS"*
{ from exclude list }
del[ete]_member service "name_SERVICE" "name_SERVICE"*
del[ete]_member certificate "name_CERTIFICATE" "name_CERTIFICATE"*
Note – *
denotes that multiple space-separated names can be specified in a
single request.
The following field may be necessary to uniquely identify an entry. If so it can be
specified after the TYPE keyword:
SCREEN "name_SCREEN"
insert Subcommand
Inserts a new object of one of the ordered (indexed) types in a specified position in
the corresponding list.
Usage:
insert rule # parameters...
insert nat # parameters...
insert accesslocal # parameters...
insert accessremote # parameters...
insert vpngateway # parameters...
276
SunScreen 3.1 Reference Manual • May 2000
Index indicates the position the new entry holds in the list after it is inserted. The
same syntax used for add is used for insert, with the index coming immediately
after the TYPE keyword.
jar_hash Subcommand
Manipulates the list of JAR hashes used by the HTTP proxy.
Usage:
jar_hash add name hash
jar_hash delete name
jar_hash rename oldname newname
jar_hash list
jar_hash list_names
TABLE B-10 describes the functions for this command.
TABLE B-10
Functions for jar_hash Subcommand
Functions
Description
add
Adds an entry to the jar_hash database.
del
Deletes an entry from the jar_hash database.
list
Lists the entries in the jar_hash database.
list_names
Lists the names of the entries in the jar_hash database.
rename
Rename an entry in the jar_hash database.
jar_sig Subcommand
Manipulates the list of JAR signatures used by the HTTP proxy.
Usage:
jar_sig add name sig-hash
jar_sig delete name
jar_sig rename oldname newname
jar_sig list
Appendix B
Command-Line Reference
277
jar_sig list_names
TABLE B-11 describes the functions for this command.
TABLE B-11
Functions for jar_sig Subcommand
Functions
Description
add
Adds an entry to the jar_sig database.
del
Deletes an entry from the jar_sig database.
list
Lists the entries in the jar_sig database.
list_names
Lists the names of the entries in the jar_sig database.
rename
Renames an entry in the jar_sig database.
list Subcommand
Displays all data for all entries or a specific entry of a given TYPE. The format of the
output is the same as the syntax of the corresponding Add TYPE request.
Usage:
*list address
list address "name_ADDRESS"
*list screen
*list screen "name_SCREEN"
*list service
list service “name_SERVICE"
*list stateengine
*list stateengine "name_STATEENGINE"
*list interface
list interface "name_INTERFACE"
*list certificate
list certificate "name_CERTIFICATE"
*list time
list time “name_TIME”
278
SunScreen 3.1 Reference Manual • May 2000
*list rule
*list rule #
*list nat
*list nat #
*list accesslocal
*list accesslocal #
*list accessremote
*list accessremote #
*list vpngateway
*list vpngateway #
The following field is optional and can be specified after the TYPE keyword in any
of the above requests except those that are preceded by an * .
SCREEN "name_SCREEN"
If no SCREEN option is present, only entries not associated with a specific SCREEN
are listed. If the SCREEN option value is * , then all entries that otherwise match
are displayed. Requests that do not specify a name always display all entries of the
given type.
list_name Subcommand
Displays the set of unique basenames and subtype of all of a given TYPE. These are
the values that can be used when another object refers to an object of the specified
TYPE.
Usage:
list_name TYPE
TYPE can be any of address, screen, service, state engine, interface, certificate, time,
or vpn.
load Subcommand
Loads a policy into the configuration editor.
Usage:
Appendix B
Command-Line Reference
279
load "name_POLICY"
Any edits to the current policy must be saved or discarded before this operation will
succeed.
lock Subcommand
ssadm lock manipulates the lock that protects a policy from simultaneous
modification by multiple administrators.
Usage:
ssadm lock -w policy
ssadm lock -c policy
ssadm lock -w prints a line of text describing the status of the lock.
ssadm lock -c forcibly breaks the lock and attempts to terminate (with a SIGHUP
signal) the previous holder of the lock.
For example:
# ssadm lock -w Initial
Lock held by [email protected] process id:8977
# ssadm lock -c Initial
# ssadm lock -w Initial
Lock available
lock_status Subcommand
Returns the status of the Lock relative to this editor. If this editor holds a lock, the
type of lock is returned. If it does not hold a lock, another process acquired a WRITE
lock, in which case, if that WRITE lock is still in effect, information about that
WRITER is presented. If that WRITE lock is no longer in effect, then Lock available
is returned.
Usage:
lock_status
280
SunScreen 3.1 Reference Manual • May 2000
search Subcommand
Searches the Registry for objects that match specified criteria.
Usage:
search TYPE [SCREEN “name_SCREEN”] [ SUBTYPE subtype ] <EXACT>
Substring…
TYPE can be any of address, screen, service, stateengine, interface, certificate, or
time. SUBTYPE values depend upon the TYPE being searched according to
TABLE B-12.
TABLE B-12
Search TYPE
TYPE
SUBTYPE
address
HOST, RANGE, GROUP
certificate
SINGLE, GROUP
interface
ADMIN, DISABLED, ROUTING, HA, STEALTH
screen
service
SINGLE, GROUP
stateengine
time
The EXACT keyword requires a substring be specified and will on match entries
whose name is an exact match.
move Subcommand
Moves an indexed entry from its current location in the ordered list to the new
location.
Usage:
move rule # #
move nat # #
move accesslocal # #
move accessremote # #
move vpngateway # #
Appendix B
Command-Line Reference
281
replace Subcommand
Replaces an object at a specified index.
Usage:
replace rule # parameters...
replace nat # parameters...
replace accesslocal # parameters...
replace accessremote # parameters...
replace vpngateway # parameters...
replace is similar to insert, except it replaces the entry at the specified index. It is
shorthand for an insert n / del n+1 pair of requests. The same syntax used for
add is used for replace, with the index coming immediately after the TYPE
keyword.
refer Subcommand
Determines if a named objects of a given TYPE is referred to in the common data or
the current policy.
Usage:
refer address "name_ADDRESS"
refer screen "name_SCREEN"
refer service "name_SERVICE"
refer stateengine "name_STATEENGINE"
refer certificate "name_CERTIFICATE"
refer time "name_TIME"
refer vpn "name_VPN"
referlist Subcommand
Displays a list of all entries in the common objects and/or the current policy that
refer to a specified named-object of a given TYPE.
282
SunScreen 3.1 Reference Manual • May 2000
Usage:
referlist address “name_ADDRESS"
referlist screen "name_SCREEN"
referlist screen "name_SCREEN"
referlist service "name_SERVICE"
referlist stateengine "name_STATEENGINE"
referlist certificate "name_CERTIFICATE"
referlist time "name_TIME”
referlist vpn "name_VPN"
rename Subcommand
Renames a specified named-object of a given TYPE.
Usage:
rename address "name_ADDRESS" "name_ADDRESS"
*rename screen "name_SCREEN" "name_SCREEN"
rename service "name_SERVICE" "name_SERVICE"
rename interface "name_INTERFACE" "name_INTERFACE"
rename certificate "name_CERTIFICATE" "name_CERTIFICATE"
rename time "name_TIME” “name_TIME"
The following field may be necessary to uniquely identify an entry. If so it can be
specified after the TYPE keyword except for the entries preceded by an * above:
SCREEN "name_SCREEN"
If an entry already exists with the new name, it is replaced by this operation.
renamereference Subcommand
Renames all references to a specified named-object of a given TYPE.
Usage:
Appendix B
Command-Line Reference
283
renamereference address "name_ADDRESS" "name_ADDRESS"
renamereference screen "name_SCREEN" "name_SCREEN"
renamereference service "name_SERVICE" "name_SERVICE"
renamereference certificate "name_CERTIFICATE" "name_CERTIFICATE"
renamereference time "name_TIME" "name_TIME"
renamereference vpn "name_VPN" "name_VPN"
save Subcommand
Saves any current edits. It also creates a new version of the policy.
Usage:
save
save "name_POLICY"
If a name is specified, then the current policy is written to the new name, but the old
policy remains the policy in the editor.
saveas Subcommand
Saves the data currently in the editor under a new name.
Usage:
saveas
saveas policy "name_POLICY"
saveas policy "name_POLICY" registry Registry
saveas policy "name_POLICY" registry "name_POLICY"
saveas policy registry Registry
These are the only supported legal requests. The first saves the current policy data
under the new name with a reference to the current common objects. The second
saves the policy data under the new name and overwrites the current common
objects with whatever is currently in the editor. This may affect other policies and
should be done with caution. The third saves the contents of the editor, policy
284
SunScreen 3.1 Reference Manual • May 2000
objects and common objects, into a single self-contained policy file of the specified
name. The last saves the common objects currently in the editor as the current
common objects and may impact other policies and should be done with caution.
reload Subcommand
Discards any and all edits (if any were made) and reloads the data into the editor
from the database. If another process has performed edits and saved them since the
current editor process loaded its data, and the current editor process wants to
perform edits, it must perform a reload first, to reacquire its read lock and ensure
that no saved edits are lost.
Usage:
reload
verify Subcommand
Takes no arguments and verifies the currently loaded policy.
Usage:
verify
mail_relay Subcommand
Manipulates the list of mail relays used by the SMTP proxy.
Usage:
mail_relay parameters
mail_spam Subcommand
Manipulates the list of spam domains used by the SMTP proxy.
Usage:
mail_spam add domain-string
mail_spam del domain-string
Appendix B
Command-Line Reference
285
mail_spam list
proxyuser Subcommand
Manipulates the list of proxy users.
Usage:
proxyuser add name parameters...
proxyuser delete name
proxyuser print
vars Subcommand
Manipulates variables used for RADIUS configuration.
Usage:
vars add variables
quit Subcommand
Causes the editor to terminate if there are no unsaved changes.
Usage:
quit
When the editor is used interactively, typing quit twice consecutively causes the
editor to terminate even if there are unsaved changes.
QUIT Subcommand
QUIT (typed in upper case) causes the editor to terminate even if there are unsaved
changes.
Usage:
QUIT
286
SunScreen 3.1 Reference Manual • May 2000
Network Monitoring and Maintenance
The following describes how to monitor and maintain your SunScreen.
Using the ssadm logdump Command
ssadm logdump is based on the Solaris snoop program and has similar
characteristics. In addition to the packet information available with snoop, ssadm
logdump also adds additional information such as the interface on which the packet
was received and the reason that the packet was logged.
For details on the ssadm logdump command, refer to the ssadm-logdump man
page.
To run ssadm logdump and display packets in the log.
# ssadm logdump -i logfile
Where log_file is a log file that is downloaded from the Screen.
Using the ssadm debug_level Command
If you have access to the console on your SunScreen (through a serial line or directly
connected CRT), you can use the ssadm debug_level command to control the
printing of debugging information from the SunScreen kernel.
If you type ssadm debug_level with no arguments, it displays the current debuglevel mask. By default, this mask is 1, which means it only reports significant errors.
If you specify a hex number as an argument for ssadm debug_level, it sets the
kernel debugging mask to that level. To get a list of debugging bit choices type:
# ssadm debug_level ?
You select a ssadm debug_level mask by setting all of the debugging bits in
which you are interested.
Appendix B
Command-Line Reference
287
Probably the most useful of the ssadm debug_level debugging bit is
DEFAULT_DROP. For example, if you type:
# ssadm debug_level 1001
any packets being dropped by SunScreen because they do not match any rule are
reported. This is a quick way to see if the SunScreen is passing packets that you
expect it to pass. You can also achieve this same result by setting the default action
on the interface to LOG_SUMMARY or LOG_DETAIL and examine the logs.
Another useful debugging bit to set is STATE_CHANGE. This causes the kernel to
report any additions or deletions from its internal state tables.
Some of the debugging bits produce a very large amount of output on a production
Screen and should be used with caution. An example is ACTION, which reports
execution of any PFL action.
Gathering Information From Your System to
Report Support Issues
If you have any support issues, call your authorized service provider. For further
information about support, use the following URL to contact Enterprise Services:
http://www.sun.com/service/support/index.html.
It is helpful to first gather information describing your configuration. This
information can be collected by saving the output of the following SunScreen
support command. You invoke these commands for information that is useful in
troubleshooting through the ssadm lib/support command.
The support command has the form:
ssadm [ -r Screen_Name ] lib/support function parameters...
See the section “Unsupported commands” on page 243.
288
SunScreen 3.1 Reference Manual • May 2000
APPENDIX
C
Services and State Engines
This appendix describes the standard services, service groups, and state engines
supported by SunScreen.
Standard Services
SunScreen is shipped with a number of predefined network services. TABLE C-1 lists
the services in SunScreen, along with the state engine and discriminator (port, RPC
program number, or type) for each service. Parameters (state engine modifiers, such
as timeouts) and BROADCAST are indicated where applicable.
TABLE C-1
SunScreen Services
Service
State Engine
(forward filtering)
Discriminator
echo
tcp
port 7
discard
tcp
port 9
systat
tcp
port 11
daytime
tcp
port 13
quote
tcp
port 17
chargen
tcp
port 19
ftp
ftp
port 21
telnet
tcp
port 23
smtp
tcp
port 25
time
tcp
port 37
State Engine
(reverse filtering)
Discriminator
289
TABLE C-1
SunScreen Services (Continued)
Service
State Engine
(forward filtering)
Discriminator
whois
tcp
port 43
nicname
tcp
port 43
dns
tcp
port 53
dns
port 53
tftp
udp
port 69
parameters
(60 –1 7)
gopher
tcp
port 70
finger
tcp
port 79
www
tcp
port 80
pop
tcp
ports
109–110
auth
tcp
port 113
ntp
udp
port 123
nntp
tcp
port 119
snmp
tcp
port 161
udp
port 161
snmp traps
udp_datagram
port 162
rlogin
tcp
port 513
rsh
rsh
port 514
syslog
udp_datagram
port 514
printer
tcp
port 515
rip
udp_datagram
port 520
port 520
(BROADCAST)
290
sqlnet
sqlnet
port 1521
archie
udp
port 1525
parameters
(360 -1 0)
certificate
discovery
udp
port 1640
parameters
(60 1 1)
SunScreen 3.1 Reference Manual • May 2000
State Engine
(reverse filtering)
Discriminator
TABLE C-1
SunScreen Services (Continued)
State Engine
(forward filtering)
Discriminator
remote
administration
tcp
ports 3852–3853
SecurID PIN
tcp
port 3855
HA
administration
tcp
port 3856
HA heartbeat
ping
port 8
HA
tcp
port 3856
securid
udp
port 5500
securidprop
tcp
port 5510
real audio
realaudio
port 7070
traceroute
udp_datagram
ports
33430–34000
Service
icmp echoreply
icmp
type 0
icmp unreach
icmp
type 3
icmp quench
icmp
type 4
icmp redirect
icmp
type 5
icmp echorequest
icmp
type 8
router
announcement
icmp
type 9
State Engine
(reverse filtering)
Discriminator
icmp
type 11
icmp
type 3
type 9
(BROADCAST)
router
solicitation
icmp
type 10
type 10
(BROADCAST)
icmp exceeded
icmp
type 11
icmp params
icmp
type 12
icmp info
icmp
types
13 14 15 16 17
18
ping
ping
port 8
Appendix C
Services and State Engines
291
TABLE C-1
SunScreen Services (Continued)
Service
router
discovery
State Engine
(forward filtering)
Discriminator
icmp
type 10
State Engine
(reverse filtering)
Discriminator
icmp
type 9
type 10
(BROADCAST)
type 9
(BROADCAST)
rstat
rusers
nfs prog
nfs readonly
prog
ypserv
mountd
ypbind
292
rpc_udp
program no.
100001
pmap_udp
program no.
100001
rpc_udp
program no.
100002
pmap_udp
program no.
100002
pmap_udp
program no.
100003
udp
port 2049
tcp
port 2049
pmap_udp
program no.
100003
nfsro
port 2049
nis
port 100004
pmap_nis
program no.
100004
pmap_nis
program no.
100004
(BROADCAST)
rpc_udp
program no.
100005
pmap_udp
program no.
100005
rpc_udp
program no.
100007
SunScreen 3.1 Reference Manual • May 2000
TABLE C-1
Service
wall
yppasswd
rquota
spray
rex
klm
nlm
status
SunScreen Services (Continued)
State Engine
(forward filtering)
Discriminator
pmap_udp
program no.
100007
rpc_udp
program no.
100008
pmap_udp
program no.
100008
rpc_udp
program no.
100009
pmap_udp
program no.
100009
rpc_udp
program no.
100011
pmap_udp
program no.
100011
rpc_udp
program no.
100012
pmap_udp
program no.
100012
rpc_udp
program no.
100017
pmap_udp
program no.
100017
rpc_udp
program no.
100020
pmap_udp
program no.
100020
rpc_udp
program no.
100021
pmap_udp
program no.
100021
rpc_udp
State Engine
(reverse filtering)
Discriminator
rpc_udp
program no.
100021
pmap_udp
program no.
100021
program no.
100024
Appendix C
Services and State Engines
293
TABLE C-1
SunScreen Services (Continued)
Service
State Engine
(forward filtering)
Discriminator
pmap_udp
program no.
100024
rpc_udp
program no.
100028
pmap_udp
program no.
100028
rpc_udp
program no.
100227
pmap_udp
program no.
100227
ospf
ip
type 89
(BROADCAST)
skip
iptunnel
type 57
ypupdate
nfs acl
type 79
icmp all
icmp
*
*
(BROADCAST)
ip all
ip
*
ip mobile
ipmobile
*
ip tunnel3
iptunnel
*
ip forward
ipfwd
*
udp all
udpall
*
tcp all
tcpall
ports 0–3850
ports 3854–
65535
294
rpc all
rpc_udp
*
rpc tcp all
rpc_tcp
*
pmap udp all
pmap_udp
*
(BROADCAST)
pmap tcp all
pmap_tcp
*
X11
tcp
ports 6000–6063
SunScreen 3.1 Reference Manual • May 2000
State Engine
(reverse filtering)
Discriminator
TABLE C-1
Service
pcnfsd
automount
SunScreen Services (Continued)
State Engine
(forward filtering)
pmap_tcp
pmap_udp
rpc_tcp
rpc_udp
pmap_tcp
pmap_udp
rpc_tcp
rpc_udp
Discriminator
program
150001
program
150001
program
150001
program
150001
no.
program
300019
program
300019
program
300019
program
300019
no.
udp
port 32649
no.
no.
no.
no.
no.
program no.
100069
pmap_udp
program no.
100069
rpc_tcp
program no.
100069
rpc_udp
program no.
100069
exec
tcp
program no.
512
wais
tcp
port 210
uucp
tcp
port 540
irc
tcp
port 6670
tcp
port 6680
tcp
tcp
port 7000
port 7010
VDOLive
Discriminator
no.
pmap_tcp
ypxfrd
State Engine
(reverse filtering)
CU See Me
udp_datagram
ports 7648–7652
Vosaic
tcp
port 1235
Appendix C
Services and State Engines
295
TABLE C-1
SunScreen Services (Continued)
Service
StreamWorks
CoolTalk
296
State Engine
(forward filtering)
udp_datagram
Discriminator
Discriminator
udp_datagram
ports 61801–
61820
udp_datagram
ports 20000–
20020
udp_datagram
port 1558
udp_datagram
port 13000
port 1558
tcp
ports 6499–6500
udp_datagram
port 13000
Backweb
udp
port 370
parameters (60
0 3)
radius
udp
port 1645
ssl
tcp
port 443
who
udp_datagram
port 513
(BROADCAST)
netstat
tcp
Port 15
biff
udp_datagram
port 512
(BROADCAST)
bootp
udp
port 67
(BROADCAST)
parameters (60
0 3)
kerberos
udp
port 88
ntp-tcp
tco
port 123
netbios name
udp
port 137
netbios
datagram
udp_datagram
port 138
netbios
session
tcp
port 139
lpd
tcp
port 2766
echo-udp
udp
port 7
discard-udp
udp
port 9
time-udp
udp
port 37
SunScreen 3.1 Reference Manual • May 2000
State Engine
(reverse filtering)
;
TABLE C-1
SunScreen Services (Continued)
Service
State Engine
(forward filtering)
Discriminator
daytime-udp
udp
port 13
tcp-high-ports
tcp
ports 1024–
65535
udp-high-ports
udp
ports 1024–
65535
esp
iptunnel
IP protocol 50
ah
iptunnel
IP protocol 51
isakmp
udp
port 500
ipv6 tunnel
iptunnel
IP protocol 41
State Engine
(reverse filtering)
Discriminator
Service information is stored in the common object registry. See “add service
Subcommand” on page 267 in Appendix B.
ftp Service
The File Transfer Protocol (FTP) is used to copy files from one system to another.
FTP is designed to work between hosts using different file structures and character
sets.
SunScreen contains an ftp state engine to screen the FTP data connection. You
specify the number for the FTP control port; the number for the FTP data port is one
less than the FTP control port number. The predefined FTP service definition, ftp,
uses the standard FTP control port number (21) and data connection port number
(20).
FTP control connections time out after a period of inactivity. The FTP server
typically closes the connect before this inactivity timeout occurs; however, if the
timeout period elapses, the quit command can take 60 seconds or more to
complete. During this time, FTP packets may be logged.
The ftp service supports both PASV and standard FTP connections. By default, ftp
service verifies that the FTP data port is 20 for standard FTP connections. To
communicate with FTP servers that do not use port 20 for the data port, modify the
ftp service definition to set its three parameters to: 600 600 1. The first parameter is
the control session timeout (600 seconds). The second parameter is the data session
timeout (600 seconds). The third parameter is a flag; a value of 1 specifies that the
system will not verify that the FTP data port is 20.
Note that this does not affect PASV FTP sessions, because they never use port 20 for
the data connection.
Appendix C
Services and State Engines
297
traceroute Service
The traceroute service entry assumes that the UDP ports being used for
traceroute are in the range of 33430-34000. If implementations of traceroute at
your site use other ports, modify the port range as appropriate.
ip Services
The ip all service is provided for backward compatibility with previous SunScreen
products. You can achieve better performance by using either the ip forward (for
IP traffic in one direction) or the ip tunnel (for IP traffic in both directions) services
instead.
Example of the old way using ip all:
“ip all” host1 host2 allow
“ip all” host2 host1 allow
Example of the new way using ip tunnel:
“ip tunnel” host1 host2 allow
The ip mobile service is provided for use with mobile, remote clients. Like the ip
tunnel service, ip mobile passes all IP traffic between a pair of addresses. Unlike
the ip tunnel service, however, a rule specifying ip mobile forces the first
connection to be made from the mobile client (a system with one of the addresses in
Source Address).
Generally, ip mobile is used for SKIP-encrypted connections with the SKIP identity
providing the authentication and access control. For example:
“ip mobile” Internet Mailhost SKIP-VERSION2
SunScreen can filter IP packets by IP protocol type alone. This is useful in special
situations such as passing non-TCP/UDP protocols or when data are being
encrypted.
If you want a Screen to pass IP packets by protocol type, you define a new service
using either the ip, ip tunnel, ip mobile, or ip fwd state engine. Specify the
protocol of the packets you wish to pass in decimal notation. If you specify * for the
protocol, the service will pass all IP packets regardless of protocol type.
298
SunScreen 3.1 Reference Manual • May 2000
There are several predefined services included, such as skip (IP protocols 79 and
57), ip tunnel, ip mobile, and ip fwd.
Caution – Using one of the state engines with a protocol specification of * (any
protocol), can be dangerous, since any traffic would be allowable. State engines
should only be used in special cases or if the data are part of an encrypted tunnel.
The predefined IP services do not pass broadcast traffic. If you want to pass
broadcast traffic, you must define a new service or add broadcast to the predefined
service.
VDOLive Service
The VDOLive service definition requires that the VDOLive clients be set to use a
fixed port, which is port 32649 by default. You can modify the service definitions so
that VDOLive will use another port.
CoolTalk Service
The CoolTalk service definition allows calls to be initiated but does not allow calls
to be received. To receive calls, define a second rule with the addresses reversed. For
example:
CoolTalk joe sam allow
CoolTalk sam joe allow
nfs readonly Service
The nfs readonly service allows read-only access to the NFSv3.0 file system.
Read-related functions, such as lookup, read, and access, are allowed. Functions
that are not read-related, such as rename and write, are blocked; traffic is not
permitted to pass under the nfs readonly rule.
Appendix C
Services and State Engines
299
smtp (Electronic Mail) Service
Simple Mail Transfer Protocol (SMTP) is used to send electronic mail between two
message transfer agents using TCP. SunScreen includes a predefined service
definition, smtp, to send and receive SMTP mail on TCP port 25.
www (World-Wide-Web Access) Service
The World Wide Web provides a graphical user interface that enables users to
browse a global network of services and documents. SunScreen contains a
predefined service definition for WWW that passes TCP connections on port 80.
Not all WWW services on the Internet use port 80; many reside on ports with other
numbers, such as 8000 or 8080. If you only allow outbound WWW access under the
www service entry, users will not be able to connect to all WWW resources. To
compensate, you can define a new TCP service that enumerates additional
nonstandard WWW ports you want to allow, or you can allow TCP access to all
ports outbound using the default service.
Caution – Do not use the tcp all service to enable inbound www access to your
public Web servers. This opens up a large security hole and allows outside users
access to any TCP service on your machines. Instead, since you know which port
your Web server uses (generally 80), you should use a more restrictive service rule,
such as the www service definition.
dns Service
DNS traffic consists of both UDP and TCP traffic. SunScreen includes a state engine
to handle the UDP DNS protocol. TCP DNS is handled through the normal TCP
state engine. To screen DNS traffic, use the predefined dns service.
rip Service
The Routing Information Protocol (RIP) is a dynamic routing protocol commonly
used by Internet routers. RIP messages are carried in UDP datagrams. SunScreen
includes a predefined service (rip) for passing RIP packets using the udpdatagram state engine with broadcast enabled. This means that a rule allows RIP
packets (including broadcasts) from source to destination.
300
SunScreen 3.1 Reference Manual • May 2000
It is usually sufficient to enable RIP in the default rule that passes RIP from the
routers to all other addresses. This lets the SunScreen send and receive RIP packets
without restriction. If you want to restrict RIP traffic, do not enable RIP using the
default access rules; instead, define rules for RIP based on your security policy.
Service
Source
Destination
Action
route
routers
*
allow
route
*
routers
allow
sqlnet Services
SunScreen contains an sqlnet state engine to screen Oracle SQL*Net protocol.
SQL*Net is Oracle’s remote data access protocol that enables client-server and
server-server communications across networks.
An Oracle client connects to the server using the port address of the listener, which
is normally defined as TCP port 1521 during Oracle installation. sqlnet service is
defined as using TCP port 1521. If Oracle is installed using a different port for the
listener, you can modify the service definition for sqlnet service accordingly.
SQL*Net connections are established in two ways. An Oracle client connects to the
listener using TCP port 1521, and the connection is established with the listener
process. With Oracle multi-threaded servers and pre-spawned server processes, the
client connects to the listener on TCP port 1521. The listener issues a redirect
message back to the client containing an IP address and port number, and the client
connects to this redirected IP address and port.
SunScreen supports both types of SQL*Net connections.
realaudio Services
SunScreen contains a service definition to handle RealAudio sessions. To screen
RealAudio traffic, use the realaudio service.
icmp Services
SunScreen includes predefined services for screening ICMP packets such as ping.
These services use the icmp state engine and allow ICMP ping request-andresponse exchanges between a Source and Destination system. Use the predefined
service ping if you want to provide ping access.
Appendix C
Services and State Engines
301
You can use the icmp state engine to create other services to pass ICMP messages of
a specific type. Most of the common ICMP packets have entries in the predefined
services, as shown in the following table:
Service
Source
Destination
Action
ping
Inside
Outside
allow
icmp-unreach
Outside Inside
allow
The above rules allow Inside machines to ping Outside machines, but block Outside
machines from sending ping messages to Inside machines. It also allows ICMP
unreachable packets to be sent from Outside machines to Inside machines. Note that
the ping service allows packets in two directions (ping-request packets from
Source to Destination and ping-response packets from Destination to Source),
while the icmp-unreach service only allows packets to flow in one direction (from
Source to Destination).
esp Services
IPsec Encapsulating Security Payload (esp) uses IP protocol 50 and is used for traffic
that has been encrypted or authenticated using IPsec.
ah Services
IPsec Authentication Header (ah) uses IP protocol 51 and is used for traffic that has
been authenticated using IPsec.
isakmp Services
Internet Security Association and Key Management Protocol provides
communication between security processes such as IKE key negotiation.
ipv6 tunnel Services
ipv6 uses IP protocol 41 and carries encapsulated IPv6 packets over an IPv4 link
such as the Internet.
302
SunScreen 3.1 Reference Manual • May 2000
ipsec
IPsec is a service group that comprises the three packet types that are used in IPsec
secure communication.
IP Packets
SunScreen can filter IP packets by IP protocol type alone. This is useful in special
situations such as passing non-TCP/UDP protocols or when data are being
encrypted.
To pass IP packets by protocol type, you need to define a new service using either
the ip, ip tunnel, ip mobile, or ip fwd state engine. Specify the protocol of the
packets you wish to pass. Note that protocol is always specified in decimal notation.
If you specify * for the protocol, this means to pass all IP packets regardless of
protocol type.
There are several predefined services included, such as skip (IP protocols 79 and
57), ip tunnel, ip mobile, and ip fwd.
Caution – Using one of the above state engines, especially with protocol specified
as * (any protocol), is very dangerous. They should only be used in special cases or
if the data are part of an encrypted tunnel.
The predefined IP services do not pass broadcast traffic. If you wish to pass
broadcast traffic, you must define a new service or add broadcast to the predefined
service.
The above rules allow Inside machines to ping Outside machines, but not vice versa.
It also allows ICMP unreachable packets to be sent from Outside machines to Inside
machines. Note that the ping service allows packets in two directions (ping-request
packets from Source to Destination and ping-response packets from Destination to
Source) while the icmp-unreach service only allows packets to flow in one
direction (from Source to Destination).
ICMP Packets
SunScreen provides predefined services for screening ICMP packets including ping.
These services are built upon the icmp state engine and allow ICMP ping requestand-response exchange to occur between a Source and Destination system. Use the
predefined service ping if you want to provide ping access.
Appendix C
Services and State Engines
303
The icmp state engine can also be used to create other services to pass ICMP
messages of a specific type. Most of the common ICMP packets have entries in the
predefined services.
Example:
Service
Source
Destination
Action
ping
Inside
Outside
accept
icmp-unreach
Outside
Inside
accept
The above rules allow Inside machines to ping Outside machines, but not vice versa.
They also allow ICMP unreachable packets to be sent from Outside machines to
Inside machines. Note that the ping service allows packets in two directions (pingrequest packets from Source to Destination and ping-response packets from
Destination to Source) while the icmp-unreach service only allows packets to flow
in one direction (from Source to Destination).
TCP Services
SunScreen screens TCP services by destination port numbers. Most common TCP
services are already defined in the service entries supplied with SunScreen.
If you need to define a new TCP service, define a new service entry specifying the
tcp filter state machine. Specify the destination TCP port or ports of the service you
wish to pass. If you specify * for the port, the service will pass all TCP services
regardless of port. Note that some services, such as FTP and RSH, cannot be passed
in this way. They are not simple TCP protocols. They make additional connections
made in the reverse direction. These services must be specified as separate services if
you wish to pass them.
The tcp state engine times out unused and silent connections five hours after a
connection has been established. Since some systems repeatedly retransmit until
they receive an error about a terminated TCP connection, you should configure a
rule using the tcp service to send an ICMP rejection message, especially on your
internal interfaces.
For example, the following rule allows telnet connections to be made from Inside
machines to Outside machines.
304
Service
Source
Destination
Action
telnet
Inside
Outside
allow
SunScreen 3.1 Reference Manual • May 2000
UDP Services
SunScreen contains several state engines to handle UDP protocols:
■
udp – Provides stateful UDP packet filtering. Allows a single request-andresponse exchange between source and destination. State entries time out in 20
seconds if no response is received.
■
udpall – Identical to udp. It is useful for avoiding conflicts while defining
service groups containing many services.
■
udp_datagram – Passes UDP packets from source to destination. You can specify
that broadcast packets should be passed.
■
udp_stateless – Allows UDP packets to be sent between source and
destination. The UDP Port(s) field specifies the list of destination UDP ports that
are allowed. The source UDP port must be a unreserved port. Note that this is a
two-way exchange of UDP packets.
Caution – Because some services use unreserved port numbers, use of this state
engine can open up security holes. Its use is not recommended.
For all UDP engines, you define a new service entry specifying the well-known
destination, UDP port. Specifying port * passes all UDP traffic.
ntp Service
SunScreen contains a state engine to handle the NTP protocol. The source and
destination UDP ports numbers are fixed at port 123. To screen NTP traffic, use the
ntp service. Broadcast NTP is not supported.
archie Service
SunScreen contains a service definition to handle the Archie UDP protocol. To screen
Archie traffic, use the archie service.
rpc Service
SunScreen contains a state engine to handle the RPC protocols. This can safely screen
RPC protocol as long as they use the portmapper and do not use dynamic RPC
program values.
Appendix C
Services and State Engines
305
To define a new RPC service, add a new service entry using both the rpc_udp and
pmap_udp state engines. You specify the well-known RPC program of the RPC
service you wish to pass. If you specify * for the RPC program, the service entry
passes all RPC services, regardless of program.
Several well-known RPC services, such as NFS and NIS, have been defined to
include all the RPC and non-RPC protocols that these systems require.
Some NFS clients use the lock manager. Since a lock manager makes connections in
both directions (to NFS server and from NFS server) you may need to use the nlm
service when you allow NFS access.
Service
Source
Destination
Action
nfs
Inside
DMZ
allow
nlm
DMZ
Inside
allow
Broadcast port mapping (NIS) is not supported for encrypted connections.
306
SunScreen 3.1 Reference Manual • May 2000
Network Service Groups
Network services can be organized into service groups, so that a single rule can
apply to multiple network services. TABLE C-2 lists the predefined service groups in
SunScreen and the services that each group includes. Note that some services are
members of more than one group, and other services are not included in any service
group.
TABLE C-2
SunScreen Network Service Groups
Service Group Name
Member Services
common
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
daytime
daytime
daytime-udp
discard
discard
discard-udp
echo
echo
echo-udp
HA
HA heartbeat
HA administration
ipsec
esp
ah
isakmp
Appendix C
Services and State Engines
307
TABLE C-2
SunScreen Network Service Groups (Continued)
Service Group Name
Member Services
mosaic
www
ssl
gopher
ftp
archie
netbios
netbios name
netbios datagram
netbios session
nfs
mountd
nfs prog
rquota
nlm
status
nfs acl
nfs readonly
mountd
nfs readonly prog
rquota
nlm
status
nfs acl
nis
ypserv
yppasswd
ypupdate
ypbind
time
time
time-udp
State Engines
SunScreen includes a number of state engines that act as a protocol checker for
services. For example, the ftp state engine checks port numbers when the ftp
service is being used.
You cannot define new state engines, and you should not change which state engine
is used by a predefined service. However, if you define a new service, you must
specify the state engine the newly defined service will use.
308
SunScreen 3.1 Reference Manual • May 2000
Characteristics of State Engines
State engines have the following characteristics:
■
Connection management—Each state engine understands the connection
management of a particular protocol or set of protocols. State engines can be
general, such as the tcp state engine, which allows a simple TCP connection, or
specific, such as the ftp state engine, which understands the FTP protocol and
parses FTP PORT and PASV commands.
■
Precedence level—Each state engine has a precedence level. A service with
multiple state engines (that is, a service group) is internally ordered by state
engine. This order is given by the order in the ss_stateengine default list.
■
Discriminator value—Each state engine has a discriminator value. This value is
used to bind the state engine to a particular service. Examples are a port number
for TCP and UDP services, an RPC program number for RPC services, or an icmp
type for ICMP services.
■
Parameters—Each state engine has a set of parameters. These parameters have a
default value that can be overridden when the service is defined to modify the
behavior of the state engine.
dns State Engine
The dns state engine is used for UDP DNS sessions. It looks inside the DNS
responses and verifies that they have the same DNS ID as the request. The
predefined service dns uses this state engine and is normally the only service to use
this state engine. Note that since the DNS service also uses the TCP protocol, the
predefined service dns also has a second entry using the tcp state engine.
The discriminator for the dns state engine is the UDP port number of the DNS
service. This is normally 53.
The dns state engine has one parameter:
■
Response timeout in seconds – Specifies the time to wait for DNS responses.
Default is 60 seconds.
ftp State Engine
The ftp state engine is used for FTP sessions. This state engine understands the
control protocol used by FTP sessions including parsing PORT commands. It
supports both traditional and PASV modes. The ftp service is typically the only
service that uses this state engine.
Appendix C
Services and State Engines
309
The discriminator for the ftp state engine is the port number of the control
connection, which is normally 21. The port number of the data session is always one
less than the control connection unless this is overridden by the parameters below.
The ftp state engine has the following parameters:
■
Lifetime of idle control session in seconds. This parameter specifies the lifetime of
an idle control session. (Default = 600 seconds)
■
Lifetime of idle data session in seconds. This parameter specifies the lifetime of an
idle data session. (Default = 600 seconds)
■
Flag value. Flag value is a set of bits. If bit 0x01 is set, non PASV data sessions are
allowed to originate from a port other than one less than the control port. This
feature is sometimes needed to communicate with FTP servers that incorrectly
implement the FTP protocol so they do not need to run the data connection as
root. (Default = 0)
icmp State Engine
The icmp state engine is used for ICMP protocols. It allows one-direction ICMP
traffic to flow.
The discriminator for the icmp state engine is the ICMP type of the packet.
The icmp state engine has no parameters.
ip State Engine
The ip state engine is a stateless filter that passes uni-directional IP traffic of a
particular IP type. The data can only flow in the forward direction (From to To
address). This state engine is supplied to provide backwards compatibility with the
ip state engine in the SunScreen SPF-100. New service definitions should use either
the ipfwd, iptunnel, or ipmobile state engines.
The discriminator for the ip state engine is the IP packet type.
The ip state engine has no parameters.
ipfwd State Engine
The ipfwd state engine allows uni-directional IP traffic of a certain IP type. The data
can only flow in the forward direction (From to To address).
The discriminator for the ipfwd state engine is the IP packet type.
310
SunScreen 3.1 Reference Manual • May 2000
The ipfwd state engine has the following parameters:
■
Cache timeout in seconds – Specifies the amount of time before the system forgets
about IP traffic between a pair of hosts. Default is 60 seconds.
■
Flag value – Must be 1.
ipmobile State Engine
The ipmobile state engine allows bidirectional IP traffic of a certain IP type. The
first connection must be initiated by the From address in the rule. Subsequent
connections can be initiated from either side as long as the cache entry has not timed
out.
The discriminator for the ipmobile state engine is the IP packet type.
The ipmobile state engine has the following parameters:
■
Cache timeout in seconds – Specifies the amount of time before the system forgets
about IP traffic between a pair of hosts. Default is 3600 seconds (1 hour).
■
Flag value – Must be 0 (zero).
iptunnel State Engine
The iptunnel state engine allows bidirectional IP traffic of a certain IP type. Either
side of the connection can initiate connections.
The discriminator for the iptunnel state engine is the IP packet type.
The iptunnel state engine has the following parameters:
■
Cache timeout in seconds – Specifies the amount of time before the system forgets
about IP traffic between a pair of hosts. Default is 60 seconds.
■
Flag value – Must be 0 (zero).
nis State Engine
The nis state engine is used to define services that are NIS UDP sessions. The
predefined service ypserv uses the nis state engine and is normally the only
service definition that uses this state engine.
The discriminator for this state engine is the RPC program number of the service.
Normally, this is always 100004, the RPC program number for NIS.
The nis state engine has the following parameters:
Appendix C
Services and State Engines
311
■
Response timeout in seconds – Specifies the time to wait for NIS responses. -1
specifies the state engine will wait forever. (Default = 60 seconds)
■
Number of expected responses per request – Typically 1, since an NIS server
sends only a single response to a request. (Default = 1)
■
Flag value – If this value is set to 2, then the system accepts NIS responses from a
different port than the NIS request port. This case occurs when an NIS server is
responding to name lookups that is mapping to DNS entries. (Default = 2)
ping State Engine
The ping state engine is used for an ICMP ping exchange. It allows ping requests
in the forward direction and ping responses in the reverse direction.
The discriminator of the ping state engine is the ICMP type of the request packet.
This is normally set to 8 to match that of an ICMP echo request packet.
The ping state engine has one parameter:
■
Response timeout in seconds – Specifies the amount of time to wait for ICMP
echo responses. Default is 10 seconds.
pmap_nis State Engine
The pmap_nis state engine is used for the portmap protocol used by NIS services. It
monitors NIS portmap requests and responses and builds a table of host/port to NIS
service mappings. The ypserv service is typically the only service definition that
uses the pmap_nis state engine.
The discriminator for the pmap_nis state engine is the RPC program number of the
service. This is always 100004, which is the RPC program number for NIS.
The pmap_nis state engine has the following parameters:
312
■
Response timeout in seconds – Specifies the time to wait for NIS portmap
responses. (Default = 60 seconds)
■
Lifetime of NIS portmap mapping entries in seconds – -1 specifies an infinite
lifetime. Since NIS clients cache portmap information indefinitely at boot time,
this value is normally set to -1. (Default = -1)
SunScreen 3.1 Reference Manual • May 2000
pmap_tcp State Engine
The pmap_tcp state engine is used for the TCP portmap protocol used by TCP RPC
services. It monitors the TCP portmap requests and responses and builds a table of
hosts and ports to RPC service mappings. Normally, a service definition for a TCP
RPC service requires both a pmap_tcp and a rcp_tcp state engine entry. The
discriminator for the pmap_tcp state engine is the RPC program number of the
service.
The pmap_tcp state engine has the following parameters:
■
Response timeout in seconds – Specifies the time to wait for portmap responses.
(Default = 60 seconds)
■
Lifetime of portmap mapping entries in seconds – -1 specifies an infinite lifetime.
(Default = 3600 seconds)
pmap_udp State Engine
The pmap_udp state engine is used for the UDP portmap protocol used by UDP
services. It monitors the UDP portmap requests and responses and builds a table of
hosts and ports to RPC service mappings. Normally, a service definition for a UDP
RPC service requires both a pmap_udp and a rpc_udp state engine entry. The
discriminator for the pmap_udp state engine is the RPC program number of the
service.
The pmap_udp state engine has the following parameters:
■
Response timeout in seconds – This parameter specifies the time to wait for
portmap responses. (Default = 60 seconds)
■
Lifetime of portmap mapping entries in seconds – -1 specifies an infinite lifetime.
(Default = 3600 seconds or 1 hour)
realaudio State Engine
The realaudio state engine is used for RealAudio sessions. This state engine
understands the control protocol used by these sessions including enabling the UDP
ports used for the audio traffic. The realaudio service is typically the only service
that uses this state engine. The discriminator for the realaudio state engine is the
port number of the TCP control connection, which is normally 7070.
The realaudio state engine has one parameter:
■
Lifetime of an idle control session in seconds – Specifies the lifetime of an idle
control session; default = 3600 seconds.
Appendix C
Services and State Engines
313
rpc_tcp State Engine
The rpc_tcp state engine is used for RPC protocols that use the TCP protocol.
Normally, a service definition for such a protocol requires both an rpc_tcp and
pmap_tcp state engine entry. The discriminator for the rpc_tcp state engine is the
RPC program number for the service.
The rpc_tcp state engine has one parameter:
■
Idle session lifetime in seconds – Specifies the lifetime of an idle TCP RCP session
in seconds. (Default = 86400 seconds or 24 hours)
rpc_udp State Engine
The rpc_udp state engine is used for RPC protocols that use the UDP protocol.
Normally, a service definition for such a protocol requires both an rpc_udp and
pmap_udp state engine entry. The discriminator for the rpc_udp state engine is the
RPC program number for the service.
The rpc_udp state engine has the following parameters:
■
Response timeout in seconds – Specifies the time to wait for RPC responses. -1
specifies to wait forever. (Default = 60 seconds)
■
Number of expected responses per request – Default is 1.
■
Flag value – Specifies whether RPC responses must come from the same host or
port that the RPC request specified. If the 0x01 bit is set, RPC responses from a
different host than the request are allowed. If the 0x02 bit is set, RPC responses
from a different port than the request port are allowed. (Default = 0)
rsh State Engine
The rsh state engine is used for remote shell (rsh) sessions. This state engine
understands the control protocol used by these sessions, including the enabling of
the TCP connection used for stderr messages. The rsh service is typically the only
service that uses this state engine. The discriminator for the rsh state engine is the
port number of the RSH server. This is normally 514.
The rsh state engine has one parameter:
■
314
Lifetime of idle session in seconds – Specifies the lifetime of an idle session.
(Default = 86400 seconds or 24 hours)
SunScreen 3.1 Reference Manual • May 2000
sqlnet State Engine
The sqlnet state engine is used for Oracle SQL*Net sessions.
It understands the network protocol used by SQL*Net, including redirected sessions
(see sqlnet Services). The sqlnet service is typically the only service using the
sqlnet state engine. Its discriminator is the port number of the Oracle listener,
which is normally TCP port 1521.
The sqlnet service is typically the only service using this state engine. The
discriminator for the sqlnet state engine is the port number of the Oracle listener,
which is normally TCP port 1521.
tcp State Engine
The tcp state engine is used for TCP sessions. This state engine allows simple TCP
connections. It cannot handle protocols, such as FTP or RSH, that have more
complicated connection management protocols, especially if they open connections
in the reverse direction. In those cases, the appropriate, more specific state engine
should be used.
The discriminator for the tcp state engine is the port number of the TCP service.
The tcp state engine has one parameter:
■
Lifetime of idle connection in seconds – Specifies the lifetime of an idle
connection; default = 86400 seconds or 24 hours.
tcpall State Engine
The tcpall state engine is used for TCP service definitions that specify a large
range of ports such as the predefined service tcp all. Since it has a lower
precedence than tcp, ftp, rsh, or realaudio, it does not override any of those
services. Normally, this state engine is only used for the predefined service tcp
all.
The discriminator for the tcpall state engine is the port number of the TCP service.
The tcpall state engine has the following parameter:
■
Lifetime of idle connection in seconds – Specifies the lifetime of an idle
connection; default = 86400 seconds or 24 hours.
Appendix C
Services and State Engines
315
udp State Engine
The udp state engine is used for UDP services. It allows one or more responses to a
UDP request. The requests are validated to make sure they come from the correct
address and port and are sent to the correct address and port. The response source
address and port checking can be modified using the parameters below.
The discriminator for the udp state engine is the port number of the UDP service.
The udp state engine has the following parameters:
■
Response timeout in seconds – Specifies the amount of time to wait for UDP
responses. -1 specifies an infinite response timeout. (Default = 60 seconds).
■
Number of responses per request – Specifies the number of expected responses
for each request. If the number of response specified is 0, any number of
responses can be received and the session terminates only after an idle period
when no responses have been received. Never specify both a response time of -1
and 0 for the number of responses per request.
■
Flag value – Specifies valid sources for UDP responses.
■
■
■
If bit 0x01 is set, the UDP response can come from a different host than the
request, which is useful for UDP services on multihomed servers that respond
using a different address.
If bit 0x02 is set, the UDP response can come from a different port than the
request.
If both bit 0x02 and bit 0x04 are set, then requests can come from a different
port than the request, and subsequent requests can also use that new port. This
is useful for handling TFTP servers that sometimes switch ports mid-session.
udpall State Engine
The udpall state engine is used for UDP services where a large number of ports are
specified. It has a lower precedence than the dns and udp state engines and does not
override services defined with those state engines. It allows one or more responses
to a UDP request. The requests are validated to make sure they come from the
correct address and port and are sent to the correct address and port. The response
source address and port checking can be modified using the parameters below.
The discriminator for the udpall state engine is the port number of the UDP
service.
The udpall state engine has the following parameters:
■
316
Response timeout in seconds – Specifies the amount of time to wait for UDP
responses. -1 specifies an infinite response timeout. (Default = 60 seconds).
SunScreen 3.1 Reference Manual • May 2000
■
Number of responses per request – Specifies the number of expected responses
for each request. If the number of response specified is 0, any number of
responses can be received and the session terminates only after an idle period
when no responses have been received. Never specify both a response time of -1
and 0 for the number of responses per request.
■
Flag value – Specifies valid sources for UDP responses.
■
■
■
If bit 0x01 is set, the UDP response can come from a different host than the
request, which is useful for UDP services on multihomed servers that respond
using a different address.
If bit 0x02 is set, the UDP response can come from a different port than the
request.
If both bit 0x02 and bit 0x04 are set, then requests can come from a different
port than the request, and subsequent requests can also use that new port. This
is useful for handling TFTP servers that sometimes switch ports mid-session.
udp_datagram State Engine
The udp_datagram state engine is used for one-way UDP protocols. It allows UDP
packets to pass in the forward direction only. It is used for services that send UDP
packets in one direction, such as syslog.
The discriminator for the udp_datagram state engine is the port number of the
UDP service.
The udp_datagram state engine has no parameters.
udp_stateless State Engine
The udp_stateless state engine is used for stateless UDP session filtering. This
engine is included for backwards compatibility with older SunScreen products, but
has been replaced in most cases with stateful UDP filtering. Note that since it is
stateless UDP packet filtering, services defined using this engine cannot safely
validate that the responses go to the same port as the request.
The discriminator for the udp_stateless state engine is the port number of the
UDP service.
The udp_stateless state engine has no parameters.
Appendix C
Services and State Engines
317
318
SunScreen 3.1 Reference Manual • May 2000
APPENDIX
D
Error Messages
This appendix describes the error messages generated by various components of the
SunScreen software and a suggested solution for each error condition.
■
Error messages from ssadm edit
■
Error messages from ssadm activate
■
Error messages from ssadm lock
■
Logged packet reasons
Error Messages From the ssadm edit
Component
Error messages can arise while editing the address, rule, and service configurations
(and from the corresponding GUIs).
The expression, [ARGUMENTS], used in the following error messages means that
the same set of arguments passed into ssadm* is echoed back.
For example, if you type:
"add address a b junk x y z"
the error message is:
"add address a b junk x y z: error_message".
The ssadm edit component’s error messages follow.
■
Usage: ssadm edit [-beim] [-I ip] [-U user] policy [-c
command]
Return code: 1
The user invoked the edit program incorrectly.
319
■
Error illegal policy name policyname
Return code: 1
The user specified an illegal policy name while invoking the editor.
■
Discarding unsaved changes
Return code:
The user chose to QUIT even though there are unsaved changes.
■
Write Lock Held
Return code:
The user asked for their lock_status, and they currently hold the write lock.
■
Read Lock Held
Return code:
The user asked for their lock_status, and they currently hold the read lock.
■
Registry Version: #
Policy Version: #
Return code: 0
The user asked for the version currently being edited.
■
no longer supported. use edit del request syntax
Return code: 251
The user tried to delete a NAT Rule using the old ssadm nat or ssadm access
command.
■
There are unsaved changes
Return code: 231
The user attempted to quit without saving unsaved changes.
■
Cannot name Policy lock
Return code: 232
The user attempted to save the policy as lock, which is a reserved word.
■
There are unsaved changes Version.
Return code: 233
The user attempted to save the policy as version, which is a reserved word.
■
320
There are unsaved changes in Registry
SunScreen 3.1 Reference Manual • May 2000
Return code: 234
The user attempted to save the policy as registry, which is a reserved word.
■
Cannot save a versioned file with a new name
Return code: 235
The user attempted to save a versioned policy with a new name.
■
Registry objects redefined
Return code:
An entry in the registry (on disk) has more than one definition. All definitions after
the first are lost upon the next save.
■
file not found
Return code: 240
The policy given to be read did not exist.
■
parse error
Return code: 241
The policy or registry file on disk is corrupt and cannot be read. Make sure you have
a back-up or a recent version saved.
■
could not acquire read lock
Return code: 242
The configuration editor could not acquire a read lock. Likely the lock file is corrupt
or some process is hanging. ss_lock -c policy is likely to be needed.
■
could not acquire write lock
Return code: 243
A request to gain the write lock failed. Likely some other process currently holds the
write lock.
■
lock not held
Return code: 244
An attempt was made to save changes, but something has happened so that this
process no longer holds the write lock. Perhaps someone else has issued an ss_lock
-c policy and invalidated the lock.
■
cannot modify "*"
Return code: 247
Appendix D
Error Messages
321
An attempt was made to modify the Address or Screen object *. This is a reserved
name and cannot be modified.
■
cannot modify "localhost"
Return code: 248
An attempt was made to modify the Address localhost. This is a reserved name and
cannot be modified.
■
lock unavailable
Return code: 249
Indicates that something happened to the lock files. ss_lock -c policy is likely
needed to fix the situation.
■
unresolved references
Return code: 250
A reference is made to a named object in the global registry that does not exist in the
registry.
■
invalid input
Return code: 251
A request was not well-formed.
■
unknown operation
Return code: 252
A request was issued for an invalid data type.
■
internal error
Return code: 253
A request used an invalid operation.
■
unknown data type
Return code: 255
No longer used.
■
Error: invalid input
Return code : nonzero : nonzero
■
Warning: Adding ADMIN Interface to an routing machine.
Indicates you added an ADMIN interface to a routing machine. You probably want
this to be a routing type interface.
322
SunScreen 3.1 Reference Manual • May 2000
■
(ssadm interfaces) Warning: operation replaced only routing
Interface
Appears as a result of an “add Interface” request
■
(ssadm interfaces) Warning: operation replaced only stealth
Interface
Appears as a result of an “add Interface” request
■
(ssadm interfaces) Warning: operation left only one stealth
Interface
Appears as a result of an “add Interface” request
Error Messages From the ssadm
activate Component
The ssadm activate component’s error messages follow.
■
Error output directory does not exist output directory
Return code : nonzero
The user invoked ssadm activate incorrectly.
■
Too many Time objects being used. Limit is 31.
Return code: 236
The policy being compiled and activated refers to more than 31 distinct time objects.
■
Registry objects redefined
Return code:
An entry in the registry (on disk) has more than one definition. All definitions after
the first are lost upon the next “save.
■
Screen object not found
Return code: 239
The -S passed to ssadm activate is a non-existent Screen object.
■
file not found
Return code: 240
The policy given to be read did not exist.
Appendix D
Error Messages
323
■
parse error
Return code: 241
The policy or registry file on disk is corrupt and cannot be read. Be sure you have a
back-up or a recent version saved.
■
compile error
Return code: 245
No longer used.
■
unresolved references
Return code: 250
A reference is made to a named object in the global registry that does not exist in the
registry.
■
Error: Status NAT, but Addresses are different sizes (NAT
entry)
Return code : nonzero
■
Error: Original and Translated Source Intersect
Return code : nonzero
■
Error: Original and Translated Destination Addresses
Intersect
Return code : nonzero
■
Error: Cannot translate both source and destination addresses
Return code : nonzero
■
Screen object must define smtp address
Return code : nonzero
The Screen object must define the SMTP Address if the SMTP proxy is to be used.
■
Error: Service not defined (remote administration)
Return code : nonzero
The indicated service is needed by the system, but the definition has either been
deleted or renamed in the global registry.
■
Error: SunScreen object has no Administrative Certificate
Screen name
Return code : nonzero
324
SunScreen 3.1 Reference Manual • May 2000
The Screen object is not fully defined. Remote administration is indicated but the
Screen is lacking a Certificate.
■
Error: SKIP and Ethernet filtering not supported
Return code: nonzero
An Ethernet-based Rule is specified (that is, a service that includes the “ether” state
engine) and it also indicates SKIP is to be used.
■
Error: More than 16 Interfaces defined for a given type
Return code: nonzero
Indicates that only 16 of a given type of interface are supported.
■
Could not find HA Service
Return code: nonzero
HA is indicated but the services “HA administration” and “HA heartbeat” have
been either removed or renamed.
■
Error: HA cluster missing HA IP Addresses
Return code: nonzero
The Screen objects participating in the current HA cluster lack HA_IP addresses.
■
Error: HA IP address is not on HA interface
Return code: nonzero
The HA IP address specified is not part of the HA interface.
■
Error: Service incorrectly defined
Return code: nonzero
A service has contradictory information, such as the same port but different state
engines, or different parameters.
■
Error: Interfaces intersect
Return code: nonzero
Two (or more) interfaces’ addresses intersect.
■
Error: Rule uses Certificate Group with Service containing
Reverse Filter RULE
Return code: nonzero
The reverse rule swaps the certificates, and groups are not supported in the
encrypting case.
Appendix D
Error Messages
325
■
Error: Rule uses Certificate Group with Service containing
Reverse State Engine RULE
Return code: nonzero
The reverse rule swaps the certificates, and groups are not supported in the
encrypting case.
■
Error: Service not defined (remote administration)
Return code: nonzero
The service is needed internally but has been either renamed or deleted.
■
Error: Service not defined (snmp traps)
Return code: nonzero
The service is needed internally but has been either renamed or deleted.
■
Error: Service not defined (skip)
Return code: nonzero
The service is needed internally but has been either renamed or deleted.
■
Error: Service not defined (certificate discovery)
Return code: nonzero
The service is needed internally but has been either renamed or deleted.
■
Error: Service not defined (rip)
Return code: nonzero
The service is needed internally but has been either renamed or deleted.
■
Error: Service not defined (dns)
Return code: nonzero
The service is needed internally but has been either renamed or deleted.
■
Error: Service not defined (nis)
Return code: nonzero
The service is needed internally but has been either renamed or deleted.
■
Error: could not generate Rule from Screen: Screen name
Return code: nonzero
■
Error: could not generate Rule to Screen: Screen name
Return code: nonzero
■
326
Error: Screen name is missing encryption parameters
SunScreen 3.1 Reference Manual • May 2000
Return code: nonzero
■
Error: Screen name requires a certificate to administer Screen
Screen name
Return code: nonzero
■
Error: Screen name requires a certificate to be administered by
Screen Screen name
Return code: nonzero
■
Error: HA Secondary with no Master
Return code: nonzero
HA is indicated, but no primary Screen is specified.
■
Error: Incomplete Screen definition
Return code: nonzero
One of the following is missing given that HA_Secondary is indicated: certificate,
key, data, mac, or compression algorithm.
■
Error: HA enabled with no HA Interface defined
Return code: nonzero
■
Error: HA enabled with multiple HA Interface(s) defined
Return code: nonzero
■
Error: HA not enabled but HA Interface(s) defined
Return code: nonzero
■
datacompiler: Error writing data file (fseek failed)
The data compiler could not write the output file owing to a failed fseek.
■
Error: Remote Certificate name1 uses multiple local
certificates: name2 and name3
A certificate name1 that is not local to this Screen is used in at least two
SKIP_VERSION_1 rules, but the local certificate is not the same. SunScreen supports
only using a one local certificate for any given remote certificate in
SKIP_VERSION_1 compatibility mode. The user must either use skip_version_2 or
change one of name2 and name3 to the other.
■
datacompiler: Manual Table too large.
Limit is 65535.
There are more than 65535 pairs of certificates for either manual keying or support
SKIP_V1 nodes. There is a limit of 65535.
Appendix D
Error Messages
327
■
datacompiler: Skip_V1 Table too large.
Limit is 65535
There are more than 65535 pairs of certificates for either Manual Keying or support
SKIP_V1 nodes. There is a limit of 65535.
■
Activation failed, error error code
Return code: 1
■
Active configuration: NAME
Activated by user on date
Return code: 0
■
Warning: Rule type could not be determined and is being
discarded Svc addr . . .
A problem determining how to implement the rule occurred and is being discarded.
■
TYPE: name is already defined. Redefined on line <#> in
file file
TYPE is address, action, service, state engine. This means that the name is defined
multiple times. One of the definitions must be removed. Using the ssadm*
command removes the first such definition. To remove the second, and keep the first
intact, you must use a text editor on the file on the Screen.
■
Error: name1 is not defined. Used on line # [in file file] by name2
Indicates an unresolved reference, where name2 refers to name1 but name1 is not
defined. The user needs to define name1 or remove the reference by modifying
name2.
■
Address name is part of a cycle
Aa circular reference in an address list definition, such that list A includes list B as a
member and list B includes list A as a member. The user must break the cycle for the
compilation to be successful.
■
Service name is part of a cycle
A circular reference in a service list definition, such that list A includes list B as a
member and list B includes list A as a member. The user must break the cycle for the
compilation to be successful.
■
Service incorrectly defined. name...
The service is internally inconsistent. Either the service defines two state engines in
the same class and subclass for the same port; or the same port and the same state
engine are used twice but with different parameters. The user must redefine this
service for the compilation to be successful.
■
328
Error: "name" is not defined. Used on line # in file FILE by
name
SunScreen 3.1 Reference Manual • May 2000
The user is referring to an object (address, service) that has not yet been defined. Be
sure it is defined.
■
Invalid Domain Name: "name"
The user has entered a domain name that has illegal characters, such as /. Use the
default domain name “default.”
■
Error: Domain "name" does not exist.
The user has entered a non-existent domain name. Use the default domain name
“default.
■
unknown operation
The user has requested an operation that is not recognized.
■
Sorry, character character not supported.
The user has entered an unsupported character.
■
could not acquire lock to read data, please re-issue request.
Too many concurrent processes are running.
■
could not acquire lock to write data, please re-issue
request.
Too many concurrent processes are running.
■
invalid input
The user entered something incorrectly. Refer to the relevant man page to verify you
have the correct command syntax.
■
unknown data type.
The user requested an operation on an unknown data type.
■
Error: "name" cannot be a Local Certificate.
The first certificate specified is supposed to be the Administration Station's
certificate. If the certificate is local to the Screen, then it cannot be the Administration
Station’s.
■
Error: Missing Remote Certificate: "name"
The first certificate could not be found in the Certificate registry, as maintained by
ssadm certificate. Be sure the entry is entered correctly.
■
Error: "name" must be a Local Certificate.
The second certificate must belong to the Screen. Try again and verify that the
second certificate is the Screen’s certificate.
■
Error: Could not find Local Certificate: "name"
Appendix D
Error Messages
329
The second certificate could not be found in the Certificate registry, as maintained by
ssadm certificate. Be sure the entry is entered correctly.
■
cannot modify Address *
The user attempted to modify *, which is not user-editable.
■
cannot modify Address "localhost"
You attempted to modify localhost, which is not user-editable.
■
Error: Service "SERVICE" not found
The user-indicated service is missing.
■
Warning: RULE uses invalid pair of certificate and will be
ignored
A SKIP-based rule must include one local and one non-local certificate. If both are
local, or both are non-local, then the rule is invalid and will be ignored. If you
believe the rule is necessary for this Screen, verify that one of the certificates is local
and one is non-local, and reactivate.
■
Warning: PROXY proxy server not found. No rule generated
The user specified proxy definition cannot be found and a proxy rule was specified.
The Rule necessary to support the proxy cannot be generated. Be sure the
appropriate proxy server is defined.
■
Error: Configuration "name" does not exist in domain name
The configuration does not exist. Try again with a configuration that does exist.
■
Error: # NAT entries are incorrectly defined
The NAT entry is invalid if its public and private addresses intersect with each other
or any other address in the NAT table. Be sure that no two NAT entries intersect.
■
Could not find HA Service
The service “HA Service” could not be found. Be sure it is defined.
■
Service incorrectly Defined: SERVICE
The specified service is not well defined. For example, it may specify the same port
for multiple state engines that conflict, like UDP and UDP-datagram.
Redefine the service correctly.
■
Error: Interface does not exist (le0)
le0 is the name of the non-existant interface. This happens if the global common
registry being activated contains an interface that the machine that is doing the
compile and activate does not have.
■
Warning: Could not verify Interface "name" exists
The user added an interface and it could not be verified on the Screen.
330
SunScreen 3.1 Reference Manual • May 2000
■
Expecting “{“ but found a character
The syntax entered was incorrect. See the man page for correct syntax.
■
Expecting “}” but found a character
The syntax entered was incorrect. See the man page for correct syntax.
■
Unexpected end of input
The syntax entered was incorrect. See the man page for correct syntax.
■
Invalid Range specified # - #
The user entered a range where the end value was less than the start value.
■
Service definition is internally inconsistent
The user specified service is not well-defined. For example, it may specify the same
port for conflicting state engines, such as UDP and UDP-datagram. Redefine the
service correctly.
Error Messages From the ssadm lock
Component
The ssadm lock component’s error messages follow:
■
Usage: ssadm lock -w | -c policy
Return code: 1
The user invoked ssadm lock command incorrectly.
■
lock held by user @ IP process id pid
The lock is held by this UNIX process with process ID pid.
Appendix D
Error Messages
331
Logged Packet Reasons – why codes
TABLE D-1 lists common reasons for logging packets in the SunScreen log and in the
SNMP syslog files. Reasons with numbers below 256 indicates that the packet
passed. Reasons with number of 256 or greater indicates that the packet was
dropped. The reason numbers listed here are sometimes referred to as why codes.
TABLE D-1
Logged Packet Reasons
Number
Log Error Message
SNMP Error Message
Explanation
1
Passed packet logged
passed(1)
Packet passed. The packet was passed
by a rule that specified the packet
should also be logged.
256
Denied or no pass
rule found
noRuleOrDenyRule(256)
Packet dropped because it did not
match any rule. Can also indicate that
the packet’s source address was invalid
for the network interface.
257
No connection
noState(257)
Packet dropped due to missing state
information. The packet was part of an
existing, possibly legal session, but no
session information could be found.
This could be due to the Screen timing
out the connection, the Screen being
rebooted and losing session state, or a
protocol violation where the initial
packets were not sent.
258
Out of memory
noMemory(258)
Packet dropped due to the lack of
Screen memory. The Screen could not
create the session state due to a lack of
real memory. The Screen will accept
new sessions when current sessions are
closed.
259
Too many connections
tooManySessions(259)
Packet dropped because the maximum
number of sessions are already open.
The Screen will accept a new session
when a current session of this type is
closed.
260
Invalid port
invalidPort(260)
Packet dropped due to invalid port
number specification. An example is an
FTP data session not on port 20.
261
Bad format
invalidFormat(261)
Packet dropped due to invalid format.
The Screen determined that the packet
did not match the service specified in
the rules.
332
SunScreen 3.1 Reference Manual • May 2000
TABLE D-1
Logged Packet Reasons (Continued)
Number
Log Error Message
SNMP Error Message
Explanation
262
Bad direction
invalidDirection(262)
Packet dropped due to invalid
“direction.” For example, a DNS
request was received when a DNS
response was expected.
263
Too many responses
tooManyResponses(263)
Packet dropped due to too many
responses. The applicable rule specified
a simple UDP exchange, but the Screen
received multiple responses.
264
Too short
tooShort(264)
Packet dropped because it was too
short for the service specified.
265
Bad protocol
invalidProtocol(265)
Packet dropped because of an invalid
protocol identifier. For example, an
RPC packet was not of protocol UDP or
TCP.
266
No port map
noPortmapEntry(266)
RPC packet dropped due to lack of port
mapping entry. An RPC packet was
received on an invalid port. This can
occur when the Screen times out RPC
portmap entries faster than the end
nodes.
267
Bad port map
invalidPortMapEntry(267)
RPC packet dropped due to invalid
port mapping entry. The portmapper
specified that a different RPC program
resides on the port.
268
NIS protocol error
nisProtocolError(268)
NIS+ packet dropped due to protocol
error (not implemented).
Appendix D
Error Messages
333
TABLE D-1
Logged Packet Reasons (Continued)
Number
Log Error Message
SNMP Error Message
Explanation
269
Bad interface
invalidInterface(269)
Indicates a “bad policy.” This error
message is typically caused by an
invalid identity. The packet was
dropped because the encryption
characteristics of the packet did not
match those specified in an otherwise
matching rule. That is, the source
address, destination address, and
service of the packet matched at least
one rule, but the encryption setting
conflicted with what was received.
Possible encryption characteristic
differences include the following:
• The packet was received encrypted,
but the rule specified that it must be
unencyrpted.
• The packet was received
unencrypted, but the rule specified
that it must encrypted.
• One of the encryption parameters of
the packet did not match a
parameter specified for the rule. For
example, a mismatching key
algorithm was used or the wrong
certificate was specified.
The encryption settings for the sender
and the Screen should be compared to
verify that they are identical and that
the correct keys are being used.
270
Bad policy
invalidPolicy(270)
A SKIP packet matched an existing
encryption rule but had one or more
parameters set incorrectly.
272
Bad source address
invalidSourceAddres(272)
Indicates a packet was dropped because
it was received on an interface where it
was not expected; that is, the packet
was dropped owing to spoof-detection
checks. If the source of the rejected
packet is supposed to be allowed on the
interface, it should be added to the
address group assigned to the interface.
274
Fragment too big
fragmentTooBig(274)
Indicates a possible network attack.
275
Fragment overlap
fragmentOverlap(275)
A packet was fragmented while it was
in transit and that the fragments
contain redundant data. May indicate a
network attack.
334
SunScreen 3.1 Reference Manual • May 2000
Appendix D
Error Messages
335
336
SunScreen 3.1 Reference Manual • May 2000
Glossary
active Screen
address
ADP
AH
algorithm
AMI
API
Argument
ATM
attack
authentication
broadcast
Screen in a high availability cluster that is keeping state and passing traffic.
There is always exactly one active Screen in a correctly operating high
availability cluster. See primary Screen and passive Screen.
In networking, a unique code that identifies a node to the network. SunScreen
uses IP addresses.
Algorithm Discovery Protocol. Enables one entity to inform another of the
capabilities it supports.
Authentication Header. A mechanism for providing strong integrity and
authentication for IP datagrams.
Sequence of steps designed to solve a problem or execute a process such as
drawing a curve from a set of control points, or encrypting a block of data.
Authentication Management Infrastructure.
application program interface. Set of calling conventions defining how a
service is invoked through a software package. An interface between the
operating system and application programs, which includes the way the
application programs communicate with the operating system, and the services
the operating system makes available to the programs.
Item of information following a command. It may, for example, modify the
command or identify a file to be affected. Sometimes the term parameter is
used.
asynchronous transfer mode. Transmits data, voice, video, and frame relay
traffic in real time. With ATM, digital information is broken up into standardsized packets, each with the address of its final destination.
Attempted cryptanalysis or an attempt to compromise system security.
Property of knowing that the claimed sender is in fact the actual sender.
Packet delivery system, where a copy of a given packet is distributed to all
hosts attached to the network.
Glossary
337
CA
cache
Buffer of high-speed memory used to store frequently accessed memory or
values. A cache increases effective memory transfer rates and processor speed.
CBC
Cipher Block Chaining (see also DES). A mode used to chain a feedback
mechanism, which essentially means the previous block is used to modify the
encryption of the next block.
CDP
Certificate Discovery Protocol. Request and response protocol used by two
parties to transfer certificates.
Centralized
Management group
certificate
certificate
authority
certificate
identifier (ID)
CFB
cipher
ciphertext
cluster
Multiple secondary Screens that are managed by the Centralized Management
group’s primary Screen. Note that a Screen in a centrally managed group,
whether primary or secondary, can also be part of a HA cluster. See HA cluster.
Data structure that binds the identity of an entity with a public-key value.
Trusted network entity that digitally signs a certificate containing information
identifying the user; such as, user’s name, issued certificate, and the
certificate’s expiration date.
Generic naming scheme term used to identify a particular self-generated or
issued certificate. It effectively decouples the identification of a key for
purposes of key lookup and access control from issues of network topology,
routing, and IP addresses.
Cipher Feedback. Uses a block cipher to implement a stream cipher.
Cryptographic algorithm used for encryption or decryption.
Encrypted message.
Screens in an HA cluster connected by a high-speed network that work
together as if they were one Screen. See high availability.
common objects
Data objects that are relevant to all SunScreen policies. They include: address,
screen, state engine, service, interface, certificate, time, and VPN gateway
groups.
confidentiality
Property of communicating such that only the sender and the intended
recipients know what is being sent, and unintended parties cannot determine
what is sent.
configuration
Union of one policy with the common objects to form a complete description of
the behavior of one or more Screens.
content filtering
338
See certificate authority.
Practice of allowing or disallowing traffic based on the content of the data
being sent.
SunScreen 3.1 Reference Manual • May 2000
decryption
demilitarized zone
Process of converting ciphertext back to plaintext.
Small protected inside network or subnetwork that provides limited public
access to resources such as web servers, FTP servers, and other information
resources.
DMZ
See demilitarized zone.
DNS
domain naming system. Distributed name and address mechanism used in the
Internet.
DST
Destination addresses.
dynamic packet
screening
Process to ALLOW or DENY examined traffic.
dynamic translation
NAT converts a set of internal private addresses into external public addresses.
It allows internal hosts to contact external hosts, but cannot be used to allow
external hosts to contact internal hosts.
encapsulation
Technique used by layered protocols in which a layer adds header information
to the protocol data unit from the layer above. In Internet terminology, for
example, a packet would contain a header from the physical layer, followed by
a header from the network layer (IP), followed by a header from the transport
layer (TCP), followed by the application protocol data. See tunneling.
encryption
Process of protecting information from unauthorized use by making the
information unintelligible. Encryption is based on a code, called a key, which is
used to decrypt the information. Contrast with decryption.
ESP
Ethernet
failover
Encapsulating Security Payload. Mechanism for providing integrity and
confidentiality to IP datagrams. In some circumstances it can also provide
authentication to IP datagrams, depending on which algorithm or algorithm
mode is used. It does not provide nonrepudiation and protection from traffic
analysis.
LAN that enables real-time communication between machines connected
directly through cables.
Process by which a passive Screen in a high availability group becomes the
active Screen if the active Screen becomes unavailable.
filter
Program that reads the standard input, acts on it in some way, and then prints
the results as standard output.
firewall
Computer situated between your internal network and the rest of the network
that filters packets as they go by according to user-specified criteria.
fragmentation
Process of dividing a packet into multiple smaller packets so that they can be
sent over a communication link that only supports a smaller size.
Glossary
339
FTP proxy
gateway
HA
HA cluster
heartbeat
A device that connects networks that use different communication protocols. It
transfers information and converts it to a compatible format to the receiving
network. See virtual private network.
See high availability.
High availability-specific groups. Multiple secondary HA cluster Screens are
managed by the primary HA cluster Screen. One Screen in an HA cluster
(secondary or primary) is the active Screen that is actively filtering. Additional
HA cluster Screens remain passive until one detects the failure of the active
HA cluster Screen and takes over the routing and filtering of the network
traffic. See high availability.
Periodic message sent between the machines within an HA cluster over a
private network to maintain state. If the heartbeat is not detected after a
specified interval and number of retries, a passive machine in the HA cluster
becomes the active machine. See high availability.
high availability
Consists of one active Screen and at least one passive Screen. If the active
Screen fails, a passive Screen takes over the filtering of the network traffic and
other functionality of the failed firewall.
host
Name of any device on a TCP/IP network that has an IP address. In SunScreen
3.1, host is only used when referring to a source or destination of a packet.
HTTP proxy
ICMP
interfaces
Initial configuration
integrity
Internet Protocol
IP
issued certificate
JDK
340
Can be configured to allow or deny specific FTP commands such as put or
get.
Can be configured to ALLOW or DENY Java applets, and Active-X controls
and cookies.
Internet Control Message Protocol. IP protocol that handles errors and control
messages, to enable routers to inform other routers (or hosts) of IP routing
problems or make suggestions of better routes. See ping.
Describes the physical interface ports of Screen objects.
When installing SunScreen, the user creates, compiles, and activates a
configuration named Initial, which enables a user to connect to the Screen
where the configurations used to implement their security policy are built.
Property of ensuring that data is transmitted from the source to destination
without undetected alteration.
Suite of protocols within TCP/IP used to link networks worldwide on the
Internet. See IP.
Internet Protocol. Network layer protocol for the Internet Protocol suite.
Certificate that is issued by a certificate authority. See self-generated certificate.
Java Development Kit. Software tools used to write Java applets or application
programs.
SunScreen 3.1 Reference Manual • May 2000
JRE
Java Runtime Environment.
key
Code for encrypting or decrypting data.
key and certificate
diskette
log browser
MAC
message transfer
agent
Medium that contains the private key and certificate, and should be kept
secure. The identifier for the certificate is on the label.
Facility in SunScreen administration GUI that enables the display and printing
of log messages.
Message Authentication Code. (Also known as media access control, an IEEE
standard.) See authentication.
The program responsible for delivering e-mail messages from a mail user agent
or other MTA.
MIB
Management Information Base. SNMP structure that describes the particular
device being monitored. See SNMP.
MTA
See message transfer agentt.
multicast
NAT
network address
translation
Special form of broadcast where copies of the packet are delivered to only a
subset of all possible destinations.
See network address translation.
Function used when packets passing through a firewall have their addresses
changed (or translated) to different network addresses. Address translation can
be used to translate unregistered addresses into a smaller set of registered
addresses, allowing internal systems with unregistered addresses to access
systems on the Internet.
network layer
Third of the seven layers in the ISO model for standardizing computer-tocomputer communications.
network mask
Number used by software to separate the local subnet address from the rest of
a given IP address.
node
nodename
nonrepudiation
Junction at which subsidiary parts originate or center.
Name by which the system is known to a communications network. Every
system running Solaris is assigned a nodename. The nodename can be
displayed using the Solaris uname -n command. Each Screen has a name that is
normally the same as the nodename.
Property of a receiver being able to prove that the sender of a message did in
fact send the message, even though the sender might later want to deny ever
having sent it.
Glossary
341
NSID
Name space identifier. Used to identify a naming scheme for a SKIP key. See
key.
OLTP
On-line transaction processing. Handles real-time transactions.
OSI
OSPF
packet
parameter
passive Screen
Open Systems Interconnection. Suite of protocols and standards sponsored by
ISO to communicate data between incompatible computer systems.
Open shortest path first. A network routing protocol.
Group of information in a fixed format that is transmitted as a unit over
communications lines.
See Argument.
Screen in a high availability cluster that is keeping state with the active Screen
but not actually passing traffic. A passive Screen will become active if the
cluster’s active Screen fails. See active Screen.
passphrase
Collection of characters used in a similar manner to, although longer than,
password. Letters in both uppercase and lowercase can be used, as well as
special characters and numbers. See password.
password
Unique string of characters that a user types as an identification code as a
security measure to restrict access to computer systems and sensitive files.
peer
Any functional unit in the same layer as another entity.
PFS
Perfect Forward Secrecy. Captured packets that are decrypted cannot be used
to decrypt other packets.
ping
plaintext
plumb
Point-to-Point
Protocol
Packet Internet Groper. Program used to test reachability of destinations by
sending them an ICMP echo request and waiting for a reply. See ICMP.
Unencrypted message.
To install and configure a network interface.
PPP (the successor to SLIP) provides router-to-router and host-to-network
connections over both synchronous and asynchronous circuits.
TCP/IP connectivity, usually for PCs over a telephone line.
policy
PPP
primary Screen
342
Named set of policy data. For example, when the SunScreen software is first
installed, it configures a default policy named Initial.
See Point-to-Point Protocoll.
In a high availability cluster, the Screen that controls the configuration of the
cluster. In a centralized management group, the Screen that controls the
configuration of the other Screens in the group. Each high availability cluster
or centralized management group has exactly one primary Screen. See high
availability.
SunScreen 3.1 Reference Manual • May 2000
private key
Corresponds to a public key and is never disclosed to the public. See secret key.
protocol
A formal description of messages to be exchanged and rules to be followed for
two or more systems to exchange information.
proxies
Proxies are separate user-level applications and provide content filtering and
user authentication. Proxies are used to control the content of various network
services. See HTTP proxy, FTP proxy, Telnet proxy, and SMTP proxy.
pseudo-random
public certificate
diskette
public-key
certificate
public-key
cryptography
real time
remote
router
routing mode
Pseudo-random numbers appear random but can be generated reliably on
different systems or at different times.
Medium that contains only the certificate containing the public key. The
identifier for the certificate is on the label
A digitally signed data structure containing a user’s public key, as well as
information about the time and date during which the certificate is valid.
Also known as asymmetric key cryptography. In public-key cryptosystems,
everyone has two related complementary keys, a publicly revealed key and a
secret key (also frequently called a private key). Each key unlocks the code that
the other key makes. Knowing the public key does not help you deduce the
corresponding secret key. The public key can be published and widely
disseminated across a communications network. This protocol provides
privacy without the need for the secure channels that a conventional
cryptosystem requires.
Event or system that must receive a response to some stimulus within a
narrow, predictable time frame, provided that the response is not strongly
dependent on highly variable system-performance parameters, such as a
processor load or interface.
System in another location that can be accessed through a network.
Intermediary device responsible for making decisions about which of several
paths network (or Internet) traffic will follow.
Routing-mode interfaces have IP addresses and perform IP routing. Routing
mode requires that you subnet the network.
All proxies are accessed through the transmission control protocol (TCP) and,
therefore, can only run on systems with at least one interface configured in
routing mode.
rules
Screen-specific
objects
Define a security policy in terms of the common data objects for SunScreen.
Policy data include filtering rules, NAT rules, and administration access rules.
Data objects relevant to the policies of one Screen. See common objects.
Glossary
343
SDNS
secondary Screen
secret key
self-generated
certificate
self-signed
certificate
Secure Data Network Service.
Screen that receives its configuration from a primary Screen. Normally, no
administration is performed on a secondary Screen. A secondary Screen does,
however, maintain its own logs and status, which can be examined. See high
availability.
Corresponds to a public key and is never disclosed to the public. See private
key.
See self-signed certificate and UDH certificate. Compare with issued certificate.
A digitally signed collection of data, whose content can be checked for
authenticity, and optionally used to check the authenticity of other digitally
signed collections (issued certificate).
In SKIP, the CA certificates are self-signed. Obtained out-of-band, they are used
as the basis for issued certificate from a CA, no matter how they are obtained
session key
SET
Secure Electronic Transaction. Protocol that is an emerging standard for
Internet bank card transactions.
shell
Program within which a user communicates with the operating system.
SKIP
Simple Key-Management for Internet Protocols. IP-layer encryption package
integrated into SunScreen, which provides a system with the ability to encrypt
any protocol within the TCP/IP suite efficiently. Once installed, systems
running SunScreen SKIP can encrypt all traffic to any SKIP-enabled product,
including SunScreen products.
SMTP
SMTP proxy
Simple Mail Transfer Protocol. Used on the Internet to route email.
TCP/IP protocol that sends messages from one computer to another on a
network and is used on the Internet to route email.
SNMP
Simple Network Management Protocol. Network management protocol that
enables a user to monitor and configure network hosts remotely.
snoop
Sun Microsystems, Inc. UNIX utility that captures packets from the network
and displays their contents.
source code
Uncompiled version of a program written in a language such as C, C++, or
Java. The source code must be translated to machine language by a program
known as the compiler before the computer can execute the program.
stateful packet filter
344
Common cryptographic component to encrypt each individual conversation
between two people with a separate key.
Packet filter that bases its decision to allow or deny the packet using both the
data in the packet and information (that is, state) saved from previous packets
or events. A stateful packet filter has memory of past events and packets.
SunScreen 3.1 Reference Manual • May 2000
stateless packet filter
Packet filter that bases its decision to allow or deny a packet using only the
data in that packet. A stateless packet filter has no memory of past events and
packets.
static translation
Address translation that provides fixed translation between an external
address and a private (possibly unregistered) address. It provides a way for
external hosts to initiate connections to internal hosts without actually using an
external address. See network address translation.
stealth mode
subnet
subnet mask
SunScreen
SunScreen SKIP
TCP
TCP/IP
Telnet proxy
traffic analysis
Transmission Control
Protocol
tunneling
Stealth-mode interfaces do not have IP addresses, and bridge the MAC layer.
Stealth mode interfaces partitions an existing single network and,
consequently, does not permit you to subnet the network. If all of your
interfaces are in stealth mode, SunScreen offers optional hardening of the OS,
which removes packages and files from the Solaris operating system that are
not used by SunScreen.
In the Internet Protocoll, a mechanism to subdivide (registered) networks into
locally defined pieces. This technique provides better use of the IP address
space while minimizing routing-table complexity. See subnet mask.
Specifies which bits of the 32-bit IP address represent network information.
The subnet mask, like an IP address, is a 32-bit binary number: a 1 is entered in
each position that will be used for network information and a 0 is entered in
each position that will be used as node number information. See node.
Name of the family of security products produced by Sun Microsystems, Inc.
See SKIP.
See Transmission Control Protocol.
Transmission Control Protocol/Internet Protocol. Protocol suite originally
developed by the Department for Defense for the Internet. It is also called the
Internet protocol suite. SunOS networks run on TCP/IP by default.
Enables users of one host to log into a remote host and interact as normal
terminal users of that host.
Analysis of network traffic flow for the purpose of deducing information such
as frequency of transmission, the identities of the conversing parties, sizes of
packets, flow identifiers used, and the like.
The protocol within TCP/IP that governs breaking data messages into packets
that are sent using IP, reassembling these packets into the complete message,
and verifying the reassembled message as the same as the original data
message.
Process of encrypting an entire IP packet, and wrapping it in another
(unencrypted) IP packet. The source and destination addresses on the inner
and outer packets may be different.
Glossary
345
tunnel address
Destination address on the outer (unencrypted) IP packet to which tunnel
packets are sent. Generally used for encrypted gateways where the IP address
of the host serves as the intermediary for any or all hosts on a network whose
topography must remain unknown or hidden from the rest of the world.
UDH certificate
Unsigned Diffie-Hellman certificate. UDH public value can be used when
entities are named using the message digest of their DH public value, and
these names are securely communicated. This term is now mostly replaced by
self-signed certificate. See certificate identifier (ID).
UDP
User Datagram Protocol. All CDP communication uses UDP.
unicast
Packet sent to a single destination. Compare broadcast, multicast.
version
Manner in which a policy’s historical versions are preserved.
virtual private
network
A network with the appearance and functionality of a regular network, but
which is really like a private network within a public one.
The use of encryption in the lower protocol layers provides a secure connection
through an otherwise insecure network, typically the Internet. VPNs are
generally cheaper than real private networks using private lines but rely on
having the same encryption system at both ends. The encryption may be
performed by firewall software or possibly by routers.
346
VPN gateway
See virtual private network.
VPN
See virtual private network.
SunScreen 3.1 Reference Manual • May 2000
Index
NUMERICS
5-tuple 143
A
access control 172
defining rules 127
overview 1
packet filtering rules 9
access level see administrative access level
action
ALLOW 105
DENY 109
ENCRYPT 112
SECURE 114
address 78
administration 49
group 80
individual 78
IP 57
range 79
address group
dialog box
dialog box
address group 80
address objects
multiple Screens 44
address range
dialog box 79
ADMIN interface
SunScreen Lite 6
administration
address 49
certificate 49
interfaces 29
administration graphical user interface. See
administration GUI
administration GUI
administrative access rules 71
browser support 10
change login password 48
command-line user interface 125, 245
default login password caution 48
defining VPN gateways 122, 124
documentation button 49, 50
elements 47
end-system SKIP 10
gateways 45
graphical user interface 11
Help button 63
Information page 49
instructions 64
interoperability with command line 244
local administration 47
localhost example 45
Login page 48
NAT 71
NAT rule mapping 121
navigation bar 49
navigation buttons 49
overview 1
packet-filtering rules 71
Policies List page 64
proxies 45
Index
347
reference 45
remote administration 47
Save As button
Edit(RO) button 68
starting 45
version number 27
VPN 71
Administration Station 49
components 12, 41
description of 2
remote administration 13, 42, 129
administration-group
certificate 49
administrative access level 47
administrative access rule
local 116
Policy Rules page 115
administrative access rules 71
remote 117
administrative user 164
authentication 158
dialog box 98
ALLOW action 105
controls 106
upgrading
ss_install 11
associate MKID
dialog box 83
authentication
external users 157
internal users 157
overview 1
authentication events 221
authorized user 98, 158
authentication 158, 171
authentication processing logic 163
creating 161
defining object 159
dialog box 98
example
create object 162
create object defining SunScreen 162
create simple-text object 163
display existing object 161
display object names 163
display objects 163
RADIUS details 173
348
SunScreen 3.1 Reference Manual • May 2000
B
backwards compatibility installation 11
BROADCAST 289
broadcast traffic 303
add broadcast 299
new service 299
browser
back, forward, and reload buttons 47
HotJava 45
log 55
Netscape Navigator 45
C
CA issued note 128
centralized management 43
certificate for Screen 89
common objects for 43
screen object 86
screen objects
screen objects 43
centralized management group
concepts 43
logs 43
primary Screen 43
secondary Screens 43
setting rules 44
SunScreen Lite 6
certificate
administration 49
administration-group 49
associate MKID 40, 83
dialog box 82
generating Screen 82
group 84
issued 128
local 49
screen object 89
ciphertext message
proxies 127
command buttons
Policy Rules page 71
command-line user interface
accessing Screen 244
administration GUI 125, 245
configuration editor 244
reference 243
commands
configuration editor 264
SunScreen SKIP commands 262
UNIX 244
unsupported 259
common objects 73
address 78
administrative user 99, 164
associate MKID certificate 40
authorized user 98, 158
automatically saved 73, 158, 194
certificate 82
components 73
data objects 15
database 73
interface 93
jar hash 100
jar signature 99
multiple Screens 44
policy rules 73
proxy user 95, 164
screen object 38, 86
service 74
time 101
compatibility
SKIP 5
SunScreen 5
components
Administration Station 2, 12, 41
Screen 2, 12, 41
configuration
common objects 15
security policy 15
configuration editor
create controlling objects 262
data model 262
object types 263
controlling objects
creating 262
controls
Policies List page 68
CoolTalk service 299
creating
screen objects 38
cryptography
authentication 128
network layer note 128
privacy 128
public-key 18, 128
shared-key 18, 128
D
data model
configuration editor 262
data object
common objects 15
database
common objects 73
decrypting packets 18, 128
decryption
function details 127
defining the name of 39
definition dialog box 93
interface 93
NAT 120
VPN 123
DENY action 109
controls 110
description 1
detail 217
dialog box 98
address range 79
administrative user 98
associate MKID 83
certificate 82
dialog box
screen object 86
host address 78
Jar hash 100
Jar signature 99
local administrative access rules 116
policy rule index 105
proxy user 95
remote administrative access rules 117
screen object Primary/Secondary tab 90
screen object SNMP tab 87
service group 76
single service 74
time 101
discriminator 309
port 289
Index
349
RPC number 289
type 289
dns service 300
dns state engine 309
documentation 6
location of HTML files 6
location of PDF files 7
documentation HTML files
location of 2
documentation PDF files
location of 2
dynamic packet filtering
details 21
function details 16
E
Edit(RO) button 68
editing 47
screen object 87
screen objects 38
editing a Screen object
SNMP tab 87
editing a screen object
Miscellaneous tab 87
Primary/Secondary tab 89
elements
administration GUI 47
ENCRYPT action 112
controls 113
encrypting packets 18, 128
encryption 48, 49
function details 127
overview 1
proxies 127
public-key cryptography 18, 128
shared-key cryptography 18, 128
SKIP 5
SunScreen Lite 6
error messages
logged packet reasons 332, 335
ssadm activate 323–331
ssadm activate 319
ssadm edit 319, 319
ssadm lock 319, 331
event logging
350
SunScreen 3.1 Reference Manual • May 2000
function details 19
F
failover protection
HA 11
feature
centralized management group 16
HA 11, 17
NAT 11, 16, 137
FTP proxy
anonymous FTP 196
controlling site access 195
destination address 195
example
display variable 197
primary Screen 198
functions 195
global version 197
limiting access to ftp commands 195
source address 195
ftp service 297
ftp state engine 297, 309
PASV mode 309
function
dynamic packet filtering 21
functions
dynamic packet filtering 16
G
global log limiter 221
graphical user interfaces
administration GUI 11
installation wizard 11
skiptool GUI 11
SunScreen SKIP 10
graphical-user interface 10
H
HA
active Screen 151
automatic disconnection 153
certificate for Screen 89
definition of 151
event log 215
failover protection 11
failure of primary Screen 152
function details 17, 151
interface 30
limitations 153
overview 1
passive Screens 18, 151
reinstate Screen 153
screen object 86
Solaris 7 for the Intel Platform limitations 153
Solaris 7 limitations 153
Solaris settings 151
state information limitations 153
SunScreen Lite 6
HA cluster
communicating with ftp and telnet to
members of 154
communication between members of 154
communication in 152
configuring 153
disrupted connections 153
failover 153
forcing failover 153
function details 18, 151
hubs necessary for 154
lost connections 153
naming Screen 154
network interfaces 152
primary Screen 151
secondary Screen 151
setting up 151
HA interface
SunScreen Lite 6
hardening OS
optional 12
stealth mode 12
help
documentation 6
man pages 6
online 6
Help button 63
high availability. See HA
host address box
dialog box 78
hostname
Screen name 39
uname -n command 39
HotJava browser 45
HTTP proxy
defining source address 198
example
display variable 199
filtering content 198
filtering Java applets 198
filtering restrictions 199
functions 198
limitations 204
NAT implementation 198
operation 202
prevent access 200
restrict Web content 200
SSL support 198
useful in implementing NAT 198
using Java 200
I
ICMP messages 23
ICMP packets 301
icmp service 301
icmp state engine 302, 310
individual IP addresses
address groups 32
address ranges 31
function details 30
modifying address note 32
individual servers
SunScreen Lite 5
Information page 49
installation 49
requirements 2
interface 1, 93
routing 1
routing mode 1
stealth mode 1
interface objects
single Screen 44
interfaces
administration 29
HA 30
HA cluster network 152
mixed routing and stealth 30
Index
351
modes 1
routing 28
routing mode 12
stealth 29
SunScreen Lite 6
internal users
authentication of
external users
authentication of 157
Internet Explorer 63
IP address
defining rules 127
IP addresses 12
ip all service 298
ip forward service 298
ip mobile service 298
ip state engine 310
ip tunnel service 298
ipfwd state engine 310
ipmobile state engine 311
iptunnel state engine 311
issued keys and certificates 128
J
Jar hash
dialog box 100
Jar hashes
VJM 204
Jar hashes and signatures
JVM 203
Jar signature
dialog box 99
Jar signatures
Jar signatures 204
Java
plug-in
installation instructions 4
Solaris 4
Windows 4
SunScreen 3.1 45
Java Virtual Machine, see JVM
JVM 203
Jar hashes 204
Jar hashes and signatures 203
352
SunScreen 3.1 Reference Manual • May 2000
K
key manager
SKIP 22
SunScreen SKIP 129
keys
issued 128
L
local
certificate 49
local administration 47
administration GUI 47
concepts 13, 42
overview 2
routing mode Screen 42
routing-mode Screen 13
URL 47
local administrative access rules
dialog box 116
Policy Rules page 116
Log
set viewing filter 55
log
administration GUI statistics 223
altering size 217
automated centrally managed group 221
automated management 221
automated postprocessing logs 221
binary records 222
bridging macros 230
centralized management global group log size
216
centralized management group 43, 215
command-line user interface statistics 223
common optional attributes 229
configuring events using command-line user
interface 220
embedded string filters 224
examining 18, 213
example
clear 222
clear log 223
debugging 221
defining specific macro 231
display global default 216
display global log limiter 220
display macro definition 231
display Screen definitions 234
display Screen names 235
display size specific Screen 217
display specific macro definition 233
displaying log statistics 223
expanding given macro 238
expanding log macro 236
get log from Screen 222
get_and_clear automatically 222
get_and_clear log 223
logapp operand 229
logsev operand 229
processing local file log record 225
processing records 225
retrieving items from current log 238
saving error message 214
setting global default 216
setting global default (250MB) 216
setting size specific Screen 217
extended events 217, 218
extended log event enhancements 229
extended log events 227, 229
filtering macros 230
filtering mechanisms 228
filtering Screen logs 224
general event type enhancements 227
get_and_clear operation 222
global default size 215
group-Screen installations 231
HA 215
HA cluster 215
installation 215
limiters 220
list verb 217
listing macros 233
local macros 230
locations 214
logdump extensions 225
logged network packet enhancements 226
logging server 224
macro expansion 237
macro name and body 232
macros 230
macros registry 230
manual management 221
naming macros 230
network session 217, 218
network traffic 217
packet filtering 221
primary Screen log file size 215
propagating limiters 221
reason why packet logged 225
retrieval and clearing 221
secondary Screen log file size 215
session summary events 227
snoop filtering 228
specific Screen 43
statistics 223
traffic size 215
using log macros 236
variable 219
who cleared log 222
log browsing
active Screen 224
administration GUI 224
log out 47
LOG_DETAIL 217
LOG_NONE 217
LOG_SESSION 218
LOG_SUMMARY 217
logged packet reasons 332–335
why codes 332
logging 18
packet logging
detail 217
none 217
summary 217
sessions 218
Login page
fields 48
M
MAC-layer bridging 12
macros
log filtering 230
Mail Proxy tab
screen object 91
spam 91
man page
ssadm logdump 287
man pages
help 6
SKIP 7
Index
353
Solaris 7
SunScreen 7
message transfer agent, see MTA
Miscellaneous tab
editing a screen object 87
multiple Screen
policy rules for 44
multiple Screens
address objects 44
common objects 44
N
names
using characters 165
naming conventions 32
NAT 71
configuration 138
definition dialog box 120
demilitarized zone 146
dynamic 141
example mappings 145
function details 137
mapping collisions 143
sequence 22
site mappings 149
stateful 138
static 139
SunScreen Lite 6
Netscape Navigator 45, 63
network address translation
ordered translations 137
network packet traffic 227
network security policy
setting up 34
network services
service groups 307
network topology
security policy 13, 41
new service
ip 298
ip fwd 298
ip mobile 298
ip tunnel 298
nfs readonly service 299
nis state engine 311
354
SunScreen 3.1 Reference Manual • May 2000
no logging 217
O
object types
configuration editor 263
named 15
ordered 15
online help 6
ordered rules sequence 23
overview
access control 1
administration GUI 1
authentication 1
encryption 1
HA 1
local administration 2
public-key encryption 1
remote administration 2
P
packet filtering
sequence 22
set up rules 9
state engine 1
stateful service rules 35
Packet Filtering tab
ALLOW action 105
DENY action 109
ENCRYPY action 112
fields on 105
Policy Rules page 104
SECURE action 114
packet logging 18, 213
packet-filtering rules 71
adding a VPN rule 125
VPN rules 125
packets
ALLOW rule 22
checking size 128
concatenated 129
creating 129
decrypting 18, 128
DENY rule 22
encapsulated 128
encrypting 18, 128
filtering 298
fragmentation 128
ICMP 301
ICMP screening guidelines 303
IP screening guidelines 303
logged error messages 319
logging 18, 213
passing RIP 300
replacing addresses 130
restoring original 130
transmission 128
tunneling 128
VPN 17, 130
parameters 309
password 49
PASV mode (FTP) 309
patches
applying 4
required 4
Solaris 2.6 4
Solaris For the Intel Platform 4
SPARC 4
x86 4
ping state engine 312
plaintext message
proxies 127
pmap_nis state engine 312
pmap_tcp state engine 313
pmap_udp state engine 313
Policies List page 64
controls 68
policy
new version 27
older version 27
rules for with multiple Screens 44
policy rule index
dialog box 105
policy rules
function details 23
ordered 23
rule syntax 24
Policy Rules page
administration GUI 103
administrative access rules 115
command buttons 71
error message 103
local administrative access rules 116
NAT tab 119
packet filtering rules 104
Packet Filtering tab 104
panel tabs 103
remote administrative access rules 117
rule definition panel 103
VPN tab 122
Policy Rules panel 103
policy versions 27
primary Screen
centralized management group 43
common objects 43
primary Screen in centralized management
SunScreen Lite 6
Primary/Secondary tab
editing a Screen object 89
proxies 6, 19
activate policy 19, 191
ciphertext message 127
client software 19, 191
content filtering 19, 191
DNS configuration 209
encryption 127
establish proxy user authenticity 194
event logging 19
example
session illustration 196
extend 157
FTP connection 197
FTP protocol 19, 191
FTP proxies 173, 194
FTP proxy collateral mapping 194
how proxies work 192
HTTP protocol 19, 191
JAR hashes 203
limitations 194
locate proxy user authenticity rule 194
multithreaded program 192
MX records 209
plaintext message 127
policy rule matching 192
protocols 191
proxy user anonymous 196
regulate 157
SecurID PIN server 191
Security Dynamics ACE/Server 173
server software 19, 191
Index
355
setting rules 19, 191
SMTP protocol 19, 191
SunScreen Lite 6
system configurations 19, 191
TCP 12
TCP only in routing mode 12
TCP protocol 192
Telnet protocol 19, 191
Telnet proxies 194
UDP protocol 192
user authentication 19, 191, 194
variables RADIUS client protocol 177
proxy user
authentication 158
creating object 167
defining object 166
dialog box 95
example
add GROUP members 169
create GROUP object 168
create SIMPLE object 168
display all names 170
display all objects 170
display objects 168
remove GROUP object 169
FTP proxies 171
GROUP object 166
GROUP objects 164
login 171
Login page 171
object definition 159
RADIUS 164
RADIUS access to LDAP 164
RADIUS LDAP stored in SDS 164
SecurID 164
SIMPLE null authentication 171
SIMPLE object 166
SIMPLE objects 164
single 95
SPECIAL external authentication method 172
special objects 164
Telnet proxies 171
public-key cryptography 18, 128
public-key encryption
overview 1
356
SunScreen 3.1 Reference Manual • May 2000
R
RADIUS
example
create address objects 176
create node secret 177
create rule 176
create variables 176
multiple-Screen installations 174
other protocol items 178
prefigured parameters 174
requestor 174
response time 178
server port 178
testing 179
testing by SDS 179
testing by SecurID 179
typical configuration 176
UDP datagrams 174
user authentication details 173
variables 174, 177
RealAudio 301
realaudio service 301, 313
realaudio state engine 313
remote administration
administration GUI 47
Administration Station 13, 42, 129
concepts 13, 42, 129
overview 2
Screen 13, 42, 129
URL 47
remote administrative access rules
dialog box 117
Policy Rules page 117
remote shell (rsh) 314
remote-access server 10
requirements
hardware 2
installation 2
patches 4
software 2
rip service
RIP packets 300
routing
interfaces 28
routing and stealth
mixed interfaces 30
routing information protocol
RIP 300
routing mode 1
capabilities 11
HA limitations 153
interfaces 12
limitations 153
remote-access server 10
subdividing a network 1
traditional firewall 10
virtual interface 1
rpc_tcp state engine 314
rpc_udp state engine 314
rsh state engine 314
remote shell sessions 314
rule
ALLOW 22
DENY 22
S
sample network map 9
Save As button 68
Screen 39, 49
active 151
active HA Screen 17
certificate for in centralized management group
89
certificate for in HA cluster 89
components 12, 41
configuration objects 43
HA limitations 153
managing multiple Screens 13
multiple management 41
passive 18, 151
reinstate 153
remote administration 13, 42, 129
remote headless 41
Screen certificate generating 82
Screen description of 2
Screen name
definition 39
hostname 39
IP address 39
screen object 38, 86
centralized management 86
certificate 89
creating 38
editing 38, 87
HA 86
Mail Proxy tab 91
Mail Proxy tab dialog box 91
Miscellaneous tab 87
Primary/Secondary tab 89
Primary/Secondary tab dialog box 90
SNMP tab dialog box 87
screening guidelines
ICMP packets 303
IP packets 303
secondary Screens
administration capabilities 43
centralized management group 43
SECURE action 114
controls 115
SecurID
access paths 183
ACE/Agent installation 182
example
token PIN establishment 188
example configuration 185
example create registry address 186
example perform stub client configuration 186
stub client 181
stub client location 182
token PIN 184
typical authentication 180
UDP and TCP protocols 188
use caution in deployment 188
security considerations 9
security network
sample network map 9
security policy
Initial 15
network topology 13, 41
ordered policy rules 23
policy objects 15
security decisions 15
version 11
service 74
group 76
single 74
service group
dialog box 76
services
Index
357
CoolTalk 299
creating new 34
discriminator 289
dns 300
ftp 297
icmp 301
IP address information 138
ip all 298
ip mobile 298
modifying 34
network service groups 307
nfs readonly 299
predefined 33
realaudio 301
realaudio state engine 313
smtp 300
sqlnet 301
standard 289
state engine 34, 289
TCP 304
tcp all 300
traceroute 298
VDOLive 299
www 300
services and service groups
creating new services 34
entries for ports 33
modifying services 34
standard services 34
session logging 218
shared-key cryptography 18, 128
single Screen
interface objects 44
single service
dialog box 74
SKIP
compatibility 5
encryption 5
key manager 22
RC2 limitation 3
SunScreen Lite 6
skiptool GUI
encryption of administration commands 11
graphical user interface 11
small work groups
SunScreen Lite 5
SMTP proxy
create rules 210
358
SunScreen 3.1 Reference Manual • May 2000
email configuration 204
email configuration issues 209
example
add restrictions 207
define address group 208
define relay restrictors 208
define spam restrictors 208
display restrictors 207
display spam restrictors 206
email rule 208
remove restriction 206, 207
functions 204
MTA filtering 210
operation 205
rules 210
spam control 205
smtp service 300
SNMP
timed status indicator 87
SNMP tab
editing a screen object 87
SNMP traps 23
SNMP traps, supported 89
snoop
IP addresses 228
snoop program 287
snoop program 130
snoop program 17
Solaris 2.6
patch 4
Solaris 2.6 for the SPARC and Intel platforms 10
Solaris 7
HA limitations 153
Solaris 7 for the Intel Platform
HA limitations 153
Solaris 7 for the SPARC and Intel platforms 10
Solaris 8 for the SPARC and Intel platforms 10
spam
Mail Proxy tab 91
SPARC
patch 4
SQL *Net protocol 301
sqlnet state engine 301
ssadm logdump
man page 287
state engine
characteristics 309
connection management 309
discriminator 289
discriminator value 309
discriminators 309
dns 309
ftp 309
icmp 310
ip 310
ipfwd 310
ipmobile 311
iptunnel 311
new service 298
nis 311
parameters 309
ping 312
pmap_nis 312
pmap_tcp 313
pmap_udp 313
precedence level 309
realaudio 313
rpc_tcp 314
rpc_udp 314
rsh 314
services 289
tcp 309, 315
tcpall 315
udp 316
udp_datagram 317
udp_stateless 317
udpall 316
state information
HA limitations 153
statistics
log file 223
stealth 1
interfaces 29
STEALTH interface
SunScreen Lite 6
stealth mode
acts as a bridge 1
capabilities 11
description 1
hardening OS 12
interfaces 12
SunScreen Lite 5
summary 217
SunScreen
command compatibility 5
compatibility 5
configuration editor 239
error messages 319
example
continue adding SecurID rules 186
how it works 10
migration from SunScreen EFS, Release 2.0 239
migration from SunScreen EFS, Release 3.0 239
migration from SunScreen SPF-200 239
upgrading 5
SunScreen 3.1
Java 45
SunScreen and SunScreen Lite
common features SunScreen Lite and SunScreen
common features 6
SunScreen compared with SunScreen Lite 5
SunScreen EFS 1.1 5
SunScreen EFS 3.0
requisites xxi
resources xxiii
SunScreen Lite 5, 6
ADMIN interface 6
centralized management group 6
encryption 6
HA 6
HA interface 6
individual servers 5
interfaces 6
limitations 5
NAT 6
number of interfaces 6
primary Screen in a centralized management 6
remote administration
remote administration
SunScreen Lite 6
SKIIP 6
small work groups 5
STEALTH interface 6
stealth mode 5
time-of-day rules 6
SunScreen Lite compared with SunScreen 5
SunScreen SKIP
commands 262
end-system SKIP 10
graphical user interface 10
header 128
Index
359
hiding addresses 130
packets 128
key manager 129
limitations note 129
log 214
SunScreen SKIP. See SKIP
U
T
TCP
proxies 12
tcp all service 300
TCP service 304
tcp state engine 315
tcpall state engine 315
Telnet proxy
example
SunScreen SKIP 212
functions 210
operation 210
other issues 211
request user name 210
TCP 211
time
dialog box 101
time objects 6
SunScreen Lite 6
time-based rules
function details 37
timed status indicator
SNMP 87
time-of-day rules
SunScreen Lite 6
traceroute service 298
traditional firewall 10
traffic key
generated 129
traffic log size 215
transmission control protocol See TCP.
troubleshooting
access to console 287
gathering information 288
printing debug information 287
ss_debug_level command 287
Trusted Solaris 7 for the SPARC platform 10
tunneling
function details 17, 130
360
SunScreen 3.1 Reference Manual • May 2000
UDP
traceroute service 298
udp state engine 316
udp_datagram state engine 317
udp_stateless state engine 317
udpall state engine 316
UNIX commands 244
unsupported commands 259
upgrading 5
Solaris support 10
Unicode internationalization note 10
upgrading from SunScreen EFS 1.1 5
URL 47
remote administration 47
user
admin 49
user authentication
administrative user 158
authuser 158
function details 157
proxy user 158
users
external 157
internal 157
V
VDOLive service 299
version
new policy 27
older policy 27
policy 27
security policy 11
version number 27
administration GUI 27
historical 27
policy versions 27
virtual private network. See VPN
VJM
Jar signatures 204
VPN 6, 71
adding a rule 125, 135
defining 132–134
definition dialog box 123
function details 17, 130
limitations 136
overview 1
setting up 17, 130
SunScreen Lite 6
tunneling data 131
W
why codes
logged packet reasons 332
www service 300
X
x86
patch 4
Index
361
">