Solaris ISP Server includes the following enhancements to the Solaris operating system:
SunTM Internet AdministratorTM
Host configuration software
Security Hardening
SunTM Internet Services MonitorTM
SunTM Directory Services
FlexLM License Server
SunScreenTM SKIP
HotJavaTM browser
JavaTM Development Kit
Sun Internet Administrator provides secure central management for distributed ISP services. It gives ISPs the following benefits:
Single sign-on for administrators. ISP administrators log in to Sun Internet Administrator once to access all functions for which they have authorization. Applications in the three-tier configuration and managed from Sun Internet Administrator receive login information from it; the user is not subsequently challenged. Three-tier services are described in "Three-Tier Service Architecture".
Administrator access control. Access is controlled per ISP service. An administrator allowed to manage FTP servers on the network may or may not also have access to news servers. Console administrators (those who can manage Sun Internet Administrator processes) have access to all managed services.
Secure communications between administrators' client machines and service hosts. Web server access control lists (ACLs) protect Sun Internet Administrator from access by unauthorized users. SSL can be used on the HTTP connection. Also, the optional SunScreen SKIP software can be installed and configured on all connections to the Sun Internet Administrator, and from it to the service host machines, encrypting those communications.
Logging of administrator actions for traceability. Each administrator action, from initial login attempt through logout, is logged via the syslog utility. This provides both troubleshooting and accountability information.
Remote management of ISP services. Services provided with Solaris ISP Server can all be managed from Sun Internet Administrator, regardless of their location on the network. Additionally, SunTM Internet FTP ServerTM, SunTM Internet News ServerTM, and SunTM Directory Services are three-tier components and receive all the security benefits built into Sun Internet Administrator. See "Three-Tier Service Architecture" and "Two-Tier Service Architecture" for more information on service interaction with Sun Internet Administrator.
Extensibility for existing services. ISPs can integrate their own applications with Sun Internet Administrator and manage them in the same way as services provided with Solaris ISP Server. See Chapter 7, Integrating Existing Service Applications for instructions on integrating applications with Sun Internet Administrator.
Sun Internet Administrator supports services in two architectures: three-tier and two-tier. Only the three-tier architecture receives all of the listed security benefits. Four types of application interfaces are supported:
Three-tier, browser-based applications receive all security benefits offered by Sun Internet Administrator.
Two-tier, browser-based applications cannot make use of the single sign-on feature, but are manageable through the Sun Internet Administrator. If they use Sun WebServer to support the administration application, they can configure it to provide administrator authentication and access control, but not single sign-on. The two-tier architecture is included to support existing applications without requiring additional programming. See Chapter 7, Integrating Existing Service Applications for details on this configuration.
X-based applications receive all the benefits of a three-tier application.
Command-line functions (scripts, programs, or in combination) receive all the benefits of three-tier applications. Any number of them can be registered for a given service and managed by Sun Internet Administrator, which constructs a web interface to the command-line programs.
The recommended three-tier browser-based application architecture receives all Sun Internet Administrator security benefits.
As shown in Figure 1-5, an administrator uses the following steps to access a service's administration functions:
From a browser, the administrator accesses either http://<hostname>:50080/ispmc or https://<hostname>:50087/ispmc (the location of the main Sun Internet Administrator GUI page).
The AWC is downloaded to the client browser, and the administrator chooses a service to manage.
Sun Internet Administrator prompts the administrator for user name and password. The administrator need not use a UNIX account for access to the user interface; a directory services repository (Sun Directory Services) manages administrator information for Sun Internet Administrator. This connection should be secured by using secure HTTP.
The selected service resolves to a URL, designating the services's ASCA. The server agent GUI is downloaded to the administrator's browser in response. At this step, control passes to the service's administration program.
Subsequent access is directly between the client browser and the application's server agent on the AWS.
The AWS authenticates the administrator against the directory services, and logs each administrator request via syslog. If the administrator has appropriate access, requests are passed to the ASCA. If not, access is denied and a log entry is made.
The ASCA communicates with the ASRA via a protocol independent of Sun Internet Administrator (chosen by the developer of the service). Appropriate IP-level security measures should be taken to protect this connection and its traffic.
The ASRA again authenticates and logs each administrator action.
To secure the communications for three-tier applications, we recommend using SSL or SunScreenTM SKIP on the client browser connection and SunScreen SKIP on all other intercomputer connections.
ASCA and ASRA modules for command-line and X-based programs are provided in Solaris ISP Server. Sun Internet Administrator uses them automatically when you register these applications.
For some applications, especially existing services, a two-tier architecture for access via Sun Internet Administrator is more practical. These services can be managed from Sun Internet Administrator, but do not receive the security benefits of single sign-on and central logging (though they can do their own logging in syslog).
As shown in Figure 1-6, an administrator uses the following steps to access a service's administration functions:
From a browser, the administrator accesses either http://<hostname>:50080/ispmc or https://<hostname>:50087/ispmc (the location of the main Sun Internet Administrator GUI page).
This step is the same as for the three-tier architecture. The AWC is downloaded to the client browser, where the administrator can choose a service to manage.
The selected service resolves to a URL, designating the component's user interface.
Subsequent access is directly between the client browser and the service's remote agent. Appropriate IP-level security measures should be taken to protect this connection and its traffic.
In a two-tier architecture, services are not able to take advantage of the single sign-on feature. If a two-tier web-based application uses Sun WebServer to support its user interface, it can configure the web server to provide the same service-level access protection as a three-tier application enjoys. See Chapter 7, Integrating Existing Service Applications for information on this configuration.
To secure the communications for a two-tier application, we recommend using SSL or SunScreen SKIP.
Sun Internet Administrator uses an instance of Sun WebServer to support its web-based user interface. This web server is referred to as the administration web server (AWS). You can, reconfigure the AWS to suit your requirements, for example to use SSL for security reasons.
Refer to the Sun WebServer online help to reconfigure the AWS. In particular, see httpd.conf(4) and the Sun WebServer on line help for configuring SSL. The web server instance that is the AWS is called "aws" in the Sun WebServer user interface.
To ensure that you do not lose the default configuration, this section discusses the location of the default AWS configuration files and the method to restore the default settings.
Backups of the AWS default configuration files are located in /etc/opt/SUNWixamc/awsconf/default/*. The files in use are at /var/opt/SUNWixamc/awsconf. To restore the default settings:
cp /etc/opt/SUNWixamc/awsconf/default/*.* /var/opt/SUNWixamc/awsconf/.
Ensure that adm has read and write access to all files.
For the effective functioning of Sun Internet Administrator, do not change the default settings in aws.conf, site.conf, map.conf, realms.conf, and access.acl.
The Solaris ISP Server host configuration software provides the following functionality:
Software installation. Administrators install, uninstall, and upgrade all Solaris ISP Server software using the host configuration software. Administrators can save installation scenarios for use in a JumpStartTM finish script to repeat installations automatically.
Solaris foundation security hardening. To improve security and conserve resources, unneeded Solaris services are disabled. Security-related components of Solaris are configured appropriately for an ISP environment.
Intrusion detection. Periodically, the intrusion detector checks its log file, determining whether any failed log-on attempts have occurred since the last check. If an intrusion attempt has occurred, the detector collects the logged data and passes it to the user-specified notification mechanism (such as electronic mail). The period for the intrusion check is configurable.
Log file management. Audit and syslog logs are cycled daily. The log file management daemon archives logs weekly and deletes any archive older than one month. See the hclfmd(1m) man page for details.
Server process management. This cron job ensures that server processes (such as news servers) are indeed running. If any server has stopped abnormally, the server process manager starts that server.
Because the typical UNIX server must run a variety of applications, the default Solaris installation assumes that most UNIX services are needed. ISPs focus more narrowly on providing specific services in a public environment. They have heavy performance and security requirements.
To configure Solaris to their needs, ISP administrators typically perform elaborate hardening tasks. They disable unneeded Solaris services and change file permissions to close security vulnerabilities. This process can take hours.
The host configuration software in Solaris ISP Server automates this hardening process for the administrator. In addition to copying the necessary software packages to their proper locations, it hardens the underlying Solaris foundation, changing file owners and modes where appropriate as well as configuring Solaris security and logging mechanisms. The final step in this process is selectively disabling standard Solaris services (such as finger or rlogin) when they do not support the purpose of a given host machine. The administrator controls which services are disabled.
Solaris ISP Server host configuration can be performed interactively by using its graphical user interface, or repeatably and non-interactively using JumpStart.
The configuration process works by building a scenario of the current state of the system, what software components are available to be installed, and what the user has selected for install or uninstall.
The host configuration software can also be used to reconfigure a host after installation, adding and removing services as needed.
Interactive host configuration (using the graphical user interface) provides the option to save a configuration scenario (in the form of a binary and some associated files). By creating and saving a scenario, the ISP administrator can use it in a JumpStart finish script, forming a non-interactive, one-step installation. Such JumpStart installations are repeatable and can be used to configure multiple machines identically.
JumpStart is a part of the Solaris operating system that can perform customized, repeatable installations of Solaris both locally and remotely. See the Solaris Advanced Installation Guide for details on how to create a custom JumpStart installation. See the Solaris ISP Server Installation Guide and the hcjump(1M) man page for information on how to use a scenario file in a finish script for a custom JumpStart installation.
The host configuration software includes a resident daemon, hclfmd, that performs log file management. This daemon runs as root. It starts at boot time and performs the following functions:
It parses the list of log files in /etc/syslog.conf for file paths that do not start with /dev (files associated with system devices) and performs a cleanup, journal, and cycle pass every day.
For every log file written by syslogd, it performs the following functions:
It renames the existing log file and creates a new daily log.
It sends the restart signal (-HUP) to the syslog daemon to create a new daily log.
It generates a weekly archive by compressing daily log files every week and stores it as name.YYYYMMDD-YYYYMMDD.tar.Z.
It discards weekly archives that are more than a month old.
It obtains the location of audit logs from /etc/security/audit_control and performs a cleanup, journal, and cycle pass every day.
It performs the following functions for every locally mounted audit directory:
It executes audit -n to create a new daily log. This signals the audit directory to close the current audit file and open a new audit file in the current audit directory.
It generates a weekly archive by compressing daily log files every week and stores it as audit.YYYYMMDD-YYYYMMDD.tar.Z.
It discards weekly archives that are more than a month old.
It performs an intrusion detection check on the interval set by the user. For details, see hclfmd(4).
It detects and reports every failed authorization entry in syslog files.
By default, /etc/opt/SUNWisp/hc/hclfmd.conf is configured to send mail to root for every failed authorization attempt entered in syslog.
You can reconfigure this file. By default, it is configured as follows: /var/log/badauth:/usr/bin/mailx -s "%f" root < %c where:
/var/log/badauth is the file where the entries are made.
/usr/bin/mailx -s is the command to send mail to root.
"%f" is the subject-line of the mail, containing the name of the file where the entries were detected.
"%c" is the new content of the syslog file.
This Solaris ISP Server component can be installed to ensure security for passwords and to safeguard file permissions to the file owner. The functionality of this unit is similar to the functionality of the script in ftp://ftp.wins.uva.nl/pub/solaris/fix-modes.tar.gz.
This component, when installed, runs a script that make modes of files installed as part of Solaris packages more secure. These changes are as follows:
Removes group and world read permissions for setuid and setgid.
Removes group and world write permissions on all non-setuid files that meet any of the following criteria:
The file has group and world readable permission, but no world writable permission.
The file has world executable permission.
The file has identical owner, group, and world permissions.
It is a bin-owned directory or nonvolatile file and has identical group and world read and executable permissions.
Removes write permissions for owners on executables not owned by root.
It adds umask 077 to /.cshrc, /.profile, and /.zshenv. This makes the default file permission for files created under an interactive root shell readable and writable only by root. If you do not want this umask, add a umask of your choice to these files prior to installing Solaris ISP Server. The configuration script will respect your settings.
It adds root to /etc/ftpusers to disable root's ability to connect to the host using FTP.
It sets noshell as the default shell for sys, uucp, nuucp, and listen accounts to log unauthorized logging attempts. This makes it easier to detect intrusion on the system.
It sets MAXWEEKS=12 in /etc/default/passwd. If local files are used for password management, this forces all passwords to change periodically.
It creates S35umask to make default file permission for files created by system daemons writable only by the file owner.
It disables a denial of service attack by adding the lines
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
It replaces /etc/syslog.conf with a new version for ensuring more granular logging and for detecting intrusion. This new version isolates messages by both facility and logging level and sends the high-level messages to a central logging server.
It executes bsmconv and configures /etc/security to log administrative actions, and logins and logouts. This enables C2 auditing, which may catch events missed by syslog.
All changes made by this unit are logged to /var/sadm/install/contents. This enables patch installation in the future.
The performance monitoring software allows an ISP to set up client machines that emulate a subscriber's experience with the ISP services. The performance monitoring applet can be set to connect to any combination of web, mail, news, and directory services and collect information on their performance from a subscriber's perspective. This data is collected on the monitoring server machine and viewable with a web browser.
Sun Internet Services Monitor is a two-tier application. It is manageable through Sun Internet Administrator, but does not receive the benefits of single sign-on or administrator authentication. See "Two-Tier Service Architecture" for more information on the two-tier architecture.
This Lightweight Directory Access Protocol (LDAP) implementation provides a shared repository for user, administrator, and service configuration information. Features in this release of Sun Directory Services include:
Conformance to LDAP v3 Internet standards
A Remote Access Dialup User Service (RADIUS) server that provides authentication for remote users connecting to the network through a Network Access Server (NAS).
A Network Information System (NIS) server that integrates into an existing NIS environment to provide an integrated naming service
A complete suite of administration tools, including the Deja directory editor, a Java-implemented administration console for management of the directory, and a web gateway for access from any Java-enabled browser
Sun Directory Services is manageable from Sun Internet Administrator as an X-based application (three-tier).
Sun Directory Services allows one thousand entries in the directory before requiring a license. A license certificate for five thousand entries ships with Solaris ISP Server and must be redeemed and registered with the FlexLM license server before it takes effect. See the instructions in the Solaris ISP Server Installation Guide for details of redeeming and installing the license certificate. Additional licenses are available from your sales representative.
See Chapter 3, Using Directory Services and Chapter 6, Solaris ISP Server Directory Schema of this book for information about the role of Sun Directory Services in Solaris ISP Server.
The FlexLM license server is used by Sun Directory Services to manage licenses of various sizes. If you already have a license server in your network (version 4.1), you can use it to serve Sun Directory Services licenses. Otherwise, install the software provided.
Sun Directory Services allows one thousand entries before requiring a license. This is sufficient to install and initialize the directory. A five thousand entry license is supplied with Solaris ISP Server. Follow the directions in the Solaris ISP Server Installation Guide for acquiring a license key and configuring the server.
This API provides C and Java programming language access to the directory services. The functions return information specific to the directory information tree (DIT) used by Solaris ISP Server.
The LDAP client library is an implementation of the LDAP v3 standard. It provides support for client applications communicating with an LDAP server such as Sun Directory Services.
This set of configuration files and scripts installs with the Sun Directory Services component. Once the directory and Sun Internet Mail Server are installed on their respective machines, a series of configuration steps aligns the two directory stores and sets up the Sun Internet Mail Server directory as a replicant (slave) of the main directory services. User information is shared across the two directories, but managed centrally from the master directory.
For complete information on configuring SIMS and the directory for interoperation, see the Solaris ISP Server 2.0 Installation Guide.
SunScreenTM SKIP is based on the Simple Key Management for Internet Protocols (SKIP) standard of key management for IP encryption. Characteristics of SunScreen SKIP include:
Automatic certificate exchanges
Sessionless protocols
Multicast and unicast packet protocols for IPv4 and IPv6
Certificate Discovery Protocol (CDP)
SunScreen SKIP provides 40-bit or 128-bit encryption, depending upon your local and United States export restrictions.
The HotJava browser is provided with Solaris ISP Server to support Sun Internet Administrator and other administration user interfaces in the product. It supports the following Internet standards and protocols:
Java Development Kit
HTTP/1.1
HTML 3.2
Tables and Frames
Persistent Cookies
GIF and JPEG Media Formats
AU Audio Format
FTP and Gopher File Transfer Protocols
SMTP and MIME E-mail Protocols
SOCKS Protocol
Secure Sockets Layer (SSL) 3.0
Java Archive (JAR) Format
The Java Development Kit (JDK) is provided with Solaris ISP Server to support the use of Java in the product. The Solaris JDK includes the following capabilities:
Internationalization
Signed applets
JAR file format
AWT (window toolkit) enhancements
JavaBeansTM component model
Networking enhancements
Math package for large numbers
Remote Method Invocation (RMI)
Reflection
Database connectivity (JDBC)
Serialization PROTOCOL_VERSION_2 (read only)