Introduction
- Secure the Operating System on Which
Your Web Server Runs
- Control against Runaway Root Privileges
- Limit Access to User Interfaces Used
to Manage Your Web Server
- Assign Strong Passwords to User Accounts
- Delete Default User Accounts That
Are No Longer Needed
- Assign Users to Groups and Organizational
Units Only as Job-Related Needs Dictate
- If You Use J2EE Realm-Based User Authentication,
Use the Type of Realm That Is Appropriate fo Your Needs
- Use the Appropriate Type of Authorization
- Greatly Restrict Dangerous Types of
Remote Access to Your Web Server
- Configure Superuser Access to Your
Administration Server Appropriately
- Configure Your Server Correctly
- Encrypt Network Transmissions
- Configure Logging Appropriately and
Read Logs Frequently
- Write Common Gateway Interface (CGI)
Scripts Properly
- Ensure That Major Vulnerabilities Are
Patched
References
Footnotes
_________________
Introduction
The Sun ONE Web Server was developed with performance, dependability,
scalability, manageability, and security in mind. A number
of measures designed for authentication, authorization, and
access control are built into this server. Achieving suitable
levels of security in the Sun ONE Web Server can be complex,
however, in large part due to the sophisticated functionality
of this Web Server. For example, the Sun ONE Web Server supports
static and dynamic content that enables having secure and
non-secure sites all within a single same Web Server, if this
is desired. This Web Server also supports two co-existing
security models, namely the:
- ACL-based security model in connection with the HTTP engine
- J2EE Servlet v2.3 specification-base in connection with
the Web container
Both of these models support services used in authenticating
and authorizing clients. Additionally, the Sun ONE Web Server
Web container provides client authentication through the Java
Authentication and Authorization Service (JAAS)-based realm
scheme, and authorization through the J2EE role-based scheme.
One of the realms,[2] the Native Realm
integrates these security models. Additionally, the Sun ONE
Web Server supports both declarative and programmatic security.
Declarative versus programmatic security is out of the scope
of these guidelines, which are intended to enable Sun ONE
Web Server Web masters achieve baseline, not advanced levels
of security. Go here
for more information about declarative versus programmatic
security.
These guidelines describe the measures needed to achieve
baseline security in Sun ONE Web Servers. These guidelines
apply to these Web Servers regardless of whether they are
managed one-by-one or collectively.
To secure your Sun ONE Web Server, you’ll need to do
the following:
- Secure the underlying operating system.
- Control against runaway root privileges.
- Limit access to user interfaces used to manage your Web
Server.
- Assign strong passwords to user accounts.
- Delete default accounts user accounts that are no longer
needed.
- Assign users to groups and organizational units only as
job-related needs dictate.
- If you use the J2EE security model, use the type of realm
that is appropriate to your needs.
- Use the type of authorization that is right for your security
needs.
- Restrict dangerous types of remote access to the Web Server.
- Configure superuser access to your Administration Server
appropriately.
- Configure your Web Server appropriately.
- Encrypt network transmissions.
- Configure logging appropriately and read logs frequently.
- Ensure that CGI or other scripts are written properly.
- Ensure that major vulnerabilities are patched
1. Secure the Operating System
on Which Your Web Server Runs
The Sun ONE Web Server runs on Unix, Linux, and Windows NT
platforms. Before you attempt to secure your Sun ONE Web Server,
you should first ensure that the operating system on which
this Web Server runs is sufficiently secure. If you fail to
secure the operating system, but tighten security in your
Sun ONE Web Server, attackers will be able to exploit operating
system vulnerabilities and will subsequently be able to successfully
attack your Sun ONE Web Server. Go here
for Baseline Security Guidelines for the major operating systems
used here at the Lab.
2. Control against Runaway
Root Privileges
Do not always run your Web Server as root. You may want to
start your Web Server as root, but constantly running your
server as root introduces several significant security threats.
For one thing, if someone exploits a vulnerability on your
Web Server while it runs as root, the likelihood of the attacker’s
obtaining unauthorized root access escalates. Additionally,
it is unadvisable to give your Web Server unrestricted access
to system resources, something that can cause your system
to be unstable and thus more susceptible to denial-of-service
attacks directed against your Web Server. The “bottom
line” is that you need to run your Web Server as an
unprivileged user. The user name you select as the server
user should be an unprivileged user account that has already
been created. Your Web Server will run out of this user account
once it starts. Note that you can run your Web Server as nobody
or an equivalent account. There may be a disadvantage to doing
so, however; in certain systems, nobody cannot run executables
(although nobody can own files).
To select the user account out of which your Web Server will
run, go to the Server Settings page. Go to the Administration
Server, choose Preferences, and then click on Server Settings.
Select the desired account and then click on OK.
3. Limit Access to User Interfaces
Used to Manage Your Web Server
To manage your Web Server, you can use the following user
interfaces:
- Sun ONE Web Server Administration Server
- Server Manager
- Class Manager
- Virtual Server Manager
To protect your Web Server against authorized and undesirable
activity, you need to ensure that only users who are assigned
the responsibility of managing your Web Server in some way
have access to any of these user interfaces. Additionally,
the more users who are given root privileges, the more likely
it is that one of them will misuse these privileges or make
a mistake that damages your Web Server and the underlying
operating system. If only two or three users need to manage
the Web Server, sharing the root password with these users
is defensible. If more than two or three users need to manage
the Web Server, you should strongly consider changing the
Administration Server user from root to a shared, unprivileged
account, or better yet multiple individual unprivileged accounts
that all belong to the same group that is used to give access
to the configuration files on the Web Server. In general,
assign users who need to manage your Web Server read and write
permissions to these files. On Windows platforms, however,
every user who is assigned the responsibility of managing
your Web Server must be a member of the Administrators group.
4. Assign Strong
Passwords to User Accounts
Whenever you create a new account, ensure that you assign
a strong (difficult-to-guess, difficult-to-crack) password.
Go here
to learn about what makes a password weak. Go here
to learn about what makes a password strong.
To change or create a password for a user account, access
the Administration Server and select the Users & Groups
tab. Display the account name. Change the password, and then
click on OK.
Note: Tthe root account is the most important one. If someone
cracks or guesses the password for this account, that person
will gain complete control over the Web Server and the operating
system on which it runs. Ensure, therefore, that the password
for the root account is unusually strong.
5. Delete Default User Accounts
that Are No Longer Needed
The more accounts there are, the more potential avenues of
unauthorized access to attackers there will be. Default accounts
are an attractive target to attackers because the names of
(and often the default passwords for) these accounts are widely
known. Accounts that are not being used (e.g., for 30 consecutive
days or more) are also attractive targets because the users
of these accounts are extremely unlikely to know that they
are being used without authorization. To delete an account,
access the Administration Server and select the Users &
Groups tab. Highlight the name of the user account and then
click on Delete User.
6. Assign Users to Groups and
Organizational Units only as Job-Related Needs Dictate
In the Sun ONE Web Server, groups and organizational units
(OUs) provide an excellent way to assign access to Web Server
resources and, if desired, roles for Web Server administration.
If users are included in groups and OUs to which they do not
need to belong, they may access information that they should
not access and may be able to make undesired changes to the
Web Server. You should thus assign users to groups and OUs
only if they need to belong to them for job-related reasons.
7. If You Use J2EE Realm-Based
User Authentication, Use the Type of Realm that Is Appropriate
to Your Needs
J2EE-based realm-based user authentication (also known as
“container-managed authentication”) offers a variety
of security realms to identify and authenticate users. Each
realm provides user information using during authentication,
something that makes a big difference as far as security is
concerned, so choosing the appropriate realm for your security
needs is critical. You have a choice between several kinds
of realms, including:
- LDAP realm. This realm allows
security information to be stored in an LDAP database, something
that is well-suited for use in connection with production
systems. To use an LDAP realm you must create the necessary
login accounts in the LDAP directory. Go to the Administration
Server’s Users & Groups tab or to your LDAP directory
product's management console.
- File realm (installation default).
The file realm authenticates users using information contained
in a text file. The following types of authentication databases
work in connection with this type of realm: keyfile-type
databases, htaccess-type databases, and digest-type databases.
The file realm is advantageous in that it is the easiest
of all to implement.
- Solaris realm. This realm, supported
only in Solaris 9, supplies Solaris login name–password
combinations during authentication. The main advantage is
being able to use a single source of information for a variety
of authentication contexts, some of which may have nothing
to do with your Web Server.
- Certificate realm. This realm
supports SSL or TLS client authentication via X.509 certificates
by establishing user identities in the Sun ONE Web Server's
security context and then filling in user data gleaned from
client certificates, such as users’ distinguished
names (DNs). The widespread popularity and availability
of certificates are major advantages of this type of realm.
- Custom realm. Server-side pluggable
Java Authentication and Authorization Service (JAAS) login
modules make it possible to create custom realms for a variety
of databases. These realms have the advantage of being customizable.
- Native realm. The already mentioned
native realm bridges the J2EE/Servlet authentication scheme
and the ACL-based authentication scheme (to be covered shortly).
By using the native realm for Java Web applications, the
ACL subsystem can authenticate users and still have their
identities for use in connection with Java Web applications—one
of the greatest advantages to using this type of realm (although
additional configuration will be necessary).
Go here
for more information concerning the J2EE-based realms.
Note that the Sun ONE Web Server also supports custom authentication
via the programmatic login interface in case the realm framework
does not fit your needs. The above URL contains more information
about this type of authentication.
8. Use the Appropriate Type of
Authorization
The Sun ONE Web Server offers role-based and Access Control
List (ACL)-based authorizations.
Role-based authorization. In role-based
authorization, users are assigned roles for which access to
resources is either allowed or denied. The Java Servlet 2.3
Specification (go here
for more information and to download) explains how to set
up access control rules that limit access to J2EE application
resources. To restrict access to specific HTML pages, servlets,
Java Server Pages (JSPs), etc., you need to specify the restricted
areas in the Web module descriptors (web.xml), the roles that
are granted access to each restricted area (in web.xml), and
the correspondence of users and groups to roles, i.e., specifying
the individual users and groups who are allowed to access
restricted areas of the Web site (in sun-web.xml). Users and
groups can be assigned multiple roles; in this case, assignment
of a user or group to at least one role that allows access
to resources is sufficient for access.
There are two methods of mapping users and groups to roles
in Sun ONE Web Servers. In “principal mapping,”
a user name or multiple names is linked directly to a role
in the sun-web.xml file. Principal mapping provides “quick
and dirty” assignment of users to roles, but it does
not scale well when the number of users in each role grows
substantially. In “group mapping” one or more
user name(s) is indirectly linked to one or more roles through
one or multiple groups in sun-web.xml. Any authenticated user
who is a member of one or more of the groups that is allowed
access gets the application role. For example, when a user
requests access to a particular Web resource, a servlet, or
a JSP, the Web container checks the security constraints associated
with the resource in the deployment descriptor files to find
out whether the user is allowed to access it.
The J2EE/Servlet authentication model is usually better for
new J2EE/Servlet-based Web applications, for dealing with
existing .war files that you do not want to change, and for
new Web applications in which full J2EE/Servlet compatibility
is critical.
ACL-based authorization. In the
ACL-based authorization ACLs — some combination of Read,
Write, Execute, Delete, List and Info — are assigned
to resources. The meaning of each type of ACL is as follows:
- Read — Enables someone to read the contents of a
file.
- Write — Enables someone to change or move a file.
Execute — Permits server-side executables to run
- Delete — Enables someone to erase a file.
[3]
- List — Permits viewing the contents of a directory.
- Info — Permits viewing meta-information about a
resource
You can set ACLs via the Sun ONE Administration Server or
via files or directories on your Web site. Settings are contained
within files with the extension .acl. Access control files
are stored in a directory (httpacl) located in a path immediately
below the server installation directory. The primary ACL file
is named “generated-https-server-id.acl” and the
temporary working file is named “genwork-https-server-id.acl.”
If you use the Sun ONE Administration Server to configure
access, you will have to access and populate entries in each
of these files. If you desire greater complexity and precision,
you can use multiple files that are referenced in server.xml.
ACLs are based on variables such as the originator of an
access request, the source host from which the request is
made, when the request occurs, and the type of connection
(e.g., SSL). For example, an entry in an ACL can allow a user
(Tim) List access, and another user (Jayne) Delete and Write
access, to a folder (data).
acl "path=/home/misc/970115.1/new/data/";
authenticate (user,group) {
database = "default";
method = "basic";
};
deny (all) (user=”anyone”);
allow (list) (user = "Tim");
allow (delete) (user = “Jayne”);
allow (write) (user = “Jayne”);
Note: Even if you choose the ACL-based scheme, you nevertheless
have the choice of using the Native Realm to propagate user
identity to make it accessible by the servlet.
9. Greatly Restrict Dangerous
Types of Remote Access to Your Web Server
Certain kinds of remote access to your Web Server are particularly
undesirable. You need to set appropriate roles or ACLs to
prevent such access. To use the Administration Server to set
ACL-based access limits on access to a certain server, for
example, access the Administration Server and select the Global
Settings tab. Click on the Restrict Access link. Choose the
desired server and click on Create ACL. The Administration
Server will show the access control rules for the Web Server
you specified. Make the changes that you want and then click
on OK.
Note: You must turn on the distributed administration function
before you can restrict server access. To enable distributed
administration, you must first install a Directory Server.
Afterwards, bring up the Administration Server and create
a special administrators group in the LDAP directory by adding
the names of users who are allowed to configure the Administration
Server or any of the servers installed in its server root.
Each user in the administrators group will have full access
to the Administration Server, but (as mentioned previously)
you can use access control to restrict the servers they will
be permitted to modify. Note also that in Windows systems,
the Sun ONE Web Server must be installed on the NTFS file
system, not the FAT file system, if you want to limit access
to critical files. The FAT file system has no permissions
to limit access.
The following files are extremely sensitive in that it would
be very advantageous for an attacker to be able to read or
modify these files:
- https-admserv/config/admpw (in the installation directory)
contains the login name and encrypted password for the superuser.
In Linux and UNIX systems, ensure that root owns this file
and that only root or the system user who runs the Administration
Server daemon can read, delete, and/or write to this file.
In Windows systems, limit ownership to the user account
that the Sun ONE Administration Server uses.
- keyfile-, digest-, and htaccess-style files are used in
authentication. Ensure that root owns all of these files
and that only root or the system user who runs the Administration
Server daemon can write to and/or delete these files.
- In Sun ONE Web Servers running on UNIX and Linux, public
access to any file with a .conf extension is dangerous.
Access to the password.conf file is, for example, dangerous
because this file contains the SSL-enabled server’s
password. The best solution is to avoid putting the SSL-enabled
server’s password in the password.conf file. Alternatively,
make root the owner of this file and ensure that only root
or the system user who runs the Administration Server daemon
is able to access this file in any way (Read, Write, Delete,
and so on). magnus.conf (the master configuration file in
Sun ONE Web Server), certmap.conf (which determines how
certificates are configured and mapped to LDAP entries),
obj.conf (which, as explained shortly, specifies paths for
which access is restricted), dbswitch.conf. (which contains
ACL entries that control access to files used in authentication),
and vsclass.obj.conf (which holds references to ACLs) must
all be protected similarly. Root must own all .conf files;
only root or the system user who runs the Administration
Server daemon should be able to write to and/or delete this
file.
- If ACLs are configured, authentication and authorization
are performed by access control rules contained in the server-install/httpacl/*.acl
files. These files are normally located in the /httpacl/
directory, but you can modify the server.xml configuration
to place them somewhere else. Ensure that root owns this
file and that only root or the system user who runs the
Administration Server daemon can write to and/or delete
this file.
Note: You also need to protect every directory that contains
one or more sensitive files. Each directory that contains
at least one sensitive file should allow Read/Write permissions
for root and the administration server user, but not others.
Web Server users should not be allowed to write to such
directories because ability to write could allow perpetrators
to create bogus versions of sensitive files and replace
the original ones with them.
- The content of most if not all Web pages should not be
modifiable by everyday users. Ensure that users do not own
Web pages and create ACLs for these pages that limit user
access to Read access (although root as well as anyone who
runs the Administration Server daemon will at a minimum
need Read, Write and Delete access.) Similarly, any Web
page for which universal access is not intended also needs
ACLs to limit access to only certain users and/or groups.
Note: You can restrict access to certain types of files
such that only certain users can read or create certain
types of files. To do this, use the Server Manager to choose
the appropriate server instance. Choose the Preferences
tab and then click on the Restrict Access link. Go to the
Pick a Resource section and then click on Wildcard. Enter
a wildcard pattern such as *.cgi. Click on Edit Access Control
and create a new rule to allow Read access to all users.
Create another rule that allows Write and Delete access
only to a specified group. Submit and apply the changes
you have made. For file type restriction, leave each Continue
box checked. If a request for access to a file is made,
the server will first examine the ACL for the file type.
A Pathcheck function will be created in obj.conf that includes
wildcards for files or directories. The entry in the ACL
file will look like the following:
acl “*.cgi”;
10. Configure Superuser Access
to your Administration Server Appropriately
Configure superuser access for your Administration Server
appropriately. Note that these settings affect access only
for the superuser account, so that if your Administration
Server uses distributed administration, you will need to create
separate access controls for members of any special administrators
group that you have created. If you use Sun ONE Directory
Server for user and group management, you must first update
the superuser entry in the directory before making any change
to the superuser login name and/or password. If you do not
do this, you will not be able to get to the Users & Groups
forms in the Administration Server. To modify the superuser
settings for the Administration Server, bring up the Administration
Server and then select the Preference tab. Click on the Superuser
Access Control link, make the appropriate changes, and then
click on OK.
11. Configure Your Server Correctly
You’ll need to do several things to ensure that your
Sun ONE Web Server is configured in a manner that is conducive
to security. This section of these guidelines describes the
most important measures for configuring your Web Server properly.
- If you need both protected and unprotected servers, segregate
the unprotected server from the protected one by running
each on a separate physical machine.
- If you have no choice but to run an unprotected Web Server
on the same physical machine as a protected Web Server,
ensure that the protected server and the unprotected server
are reachable on different port numbers—TCP port 80
for the unprotected Web Server and 443 for the protected
one. To do this, you must set up the appropriate “listen
sockets.” Installation of your Sun ONE Web Server
results in one listen socket (ls1), which uses the IP address
0.0.0.0 and the port number designated as the one for the
HTTP server during installation. The default HTTP port is
TCP 80. The default listen socket cannot be deleted, but
you can add additional listen sockets by editing the Server
Manager’s Listen Sockets Table. Access the Server
Manager and then click on the Preferences tab. Click on
the Edit Listen Sockets link. Change the table as desired
and then click on OK.
- If you run the Sun ONE Web Server on UNIX or Linux, chroot
the document root directory. If (as shown in the figure
below) the root directory is /d1/ms and this directory is
chrooted, users who try to get to the root directory (/)
cannot get there, nor can they get to the /d1 directory.
Users who try to get to /bin will instead get to /d1/ms/bin.
This not only protects against unauthorized access to the
root directory, but it also helps keep unauthorized users
away from other critical directories and their contents.
Note that in the Sun ONE Web Server chrooting requires that
you create a full directory structure required by the Web
Server, as shown below:
Note also that you need to set up separate http, dev, bin
and lib directories with the appropriate content in each.
Compartmentalizing the directory structure makes it much more
difficult to an attacker who obtains access to one directory
to do very much damage to your Web Server very quickly. Unless
the attacker can quickly determine what other directories
exist and how to get to them, potential damage is likely to
be limited to the one directory.
To chroot a directory in an individual virtual server,[4]
go to the Server Manager and then choose the server instance
from the drop-down menu. Choose the Virtual Server Class tab.
Click on the link for the virtual server that you desire from
the Tree View of the Server. Choose the Settings tab. The
Settings page will be displayed. Enter the full pathname in
the Set to field that is located next to Chroot Directory.
Click on OK and then click on Apply. Finally, select Load
Configuration Files to apply the new setting.
You can also chroot a directory for a virtual server class.
Access the Server Manager and choose the server instance from
the drop-down menu. Choose the Virtual Server Class tab. Click
on the Edit Classes link, ensuring that the Option is Edit
for the desired virtual server class. Click on the Advanced
button for this class. The Virtual Servers’ CGI Settings
page will appear. Enter the full pathname in the Chroot field.
Click on OK and then click on Apply. Finally, select Load
Configuration Files to apply the new setting.
12. Encrypt Network Transmissions
Cleartext network transmissions, particularly those in which
passwords and/or sensitive information are being sent, escalate
security risk substantially. Enabling transport layer encryption
on each instance of Administration Server that will be accessed
is thus imperative. Additionally, enabling transport layer
encryption for user access is also very important. At least
one server certificate[5] must be installed
first. Additionally, settings for the tlsrollback parameter
may affect the ability to achieve encrypted sessions between
your Web Server and clients.[6] Contexts
in which this kind of encryption needs to be enabled include
the following:
- Administration Server Communication with LDAP.
To enable SSL access the Administration Server and select
the Global Settings tab. Click on the Configure Directory
Service link. Choose Yes for the option to Secure Sockets
Layer (SSL) for connections. Click on Save Changes. Click
on OK to change the port to the standard port (TCP 636)
for LDAP over SSL.
- Using Listen Sockets—Enabling Security
when Creating[7] a Socket. Bring
up the Server Manager. Using the drop-down menu, choose
the server instance in which the listen socket will be created.
Choose the Preferences tab. Select the Edit Listen Sockets
link. The Edit Listen Sockets page will appear. Click on
the New button. The Add Listen Socket page will be displayed.
Enter the required data and choose a default virtual server.
Choose Enabled from the Security drop-down menu. Click on
OK. Click on Apply and then click on Restart to make changes
go into place. Chose a server certificate for the listen
socket. Select the desired cipher(s) from among SSL 2.0,
SSL 3.0, and TLS (see below for more information about choices
of ciphers). Note that enabling SSL and TLS on a listen
socket for the Server Manager sets security preferences
for every virtual server that works in connection with that
listen socket.
- Using Listen Sockets—Enabling Security
when Editing a Socket. Bring up either the
Administration Server or the Server Manager and choose the
Security tab. For the Server Manager you must first choose
the server instance from the drop-down menu. Chose the Preferences
tab. Select the Edit Listen Sockets link. The Edit Listen
Sockets page will appear. To edit a listen socket, click
on the Listen Socket ID of the desired listen socket. The
Edit Listen Socket page will be shown. To enable security,
select Enabled from the Security drop-down menu. Click on
OK. For the Server Manager, click on Apply and then on Restart
to put the changes in effect.
To enable SSL and TLS, bring up the Administration Server
or the Server Manager and select the Preferences tab. For
the Server Manager you must select the desired server instance
from the drop-down menu. Click on the Edit Listen Sockets
link. The Edit Listen Sockets page will be displayed. The
Edit Listen Socket page will show the available cipher settings
for a secure listen socket. Check the checkboxes corresponding
to the desired types of encryption.[8]
Click on OK. For the Server Manager, click on Apply, and
then on Restart to put the changes in effect.
Note: You should not choose the “No Encryption, only
MD5 message authentication” option. If the client does
not have any ciphers, your Web Server will default to this
setting, resulting in cleartext network transmissions between
the client and your Web Server.
- Configuring Security Globally.
Security must be enabled if virtual server security settings
are going to go in effect. SSL properties for each virtual
server are in the SSLPARAMS element in server.xml. To set
SSL configuration file directive parameters, bring up the
Server Manager and then choose the server instance of the
virtual server from the drop-down menu. Confirm that security
for the desired listen socket is enabled. Click on the Edit
Listen Sockets link. Click on the Listen Socket ID that
corresponds to the desired listen socket. The Edit Listen
Socket page will appear. Choose Enabled from the Security
drop-down menu. Click on OK. Click on the Magnus Editor
link. Choose SSL Settings from the drop-down menu and then
click on Manage. Enter the values for SSLSessionTimeout
(suggested value: 60 minutes), SSLCacheEntries (no value
suggested), and SSL3SessionTimeout (suggested value: 60
minutes). Click on OK. Click on Apply and then on Restart
to put changes into effect.
13. Configure Logging Appropriately
and Read Logs Frequently
The Sun ONE Web Server logs a wide range of events that can
help you identify attacks against your Web Server and also
to decide whether they were successful. To benefit from logging,
you need to configure logging appropriately and read the logs
frequently.
An access log file, “access,” is created for
the Sun ONE Web Server during installation. The Log Preferences
page allows you to choose the kind and format of information
recorded in the Administration Server logs. You can, for example,
log data about every client that connects to the Administration
Server or you can exclude entries for selected clients. You
can also select the Common Logfile Format, something that
delivers a predetermined amount of data about your Web Server,
or you can invent your own log file format. You can in fact
customize access logging for any resource.
To select log preferences, access the Administration Server
Log Preferences page by selecting the Preferences tab and
then clicking on the Logging Options link. If you want to
modify the format of an existing log file, first delete or
rename the existing log file. Server access logs are in Common
Logfile Format (a frequently supported format that yields
a constant quantity of information concerning the server),
flexible log format (one that enables you to select what is
logged), or your own, customized format that allows you to
designate whether to log accesses, the particular logging
format to use, and whether the server should look up domain
names of clients that have accessed a resource. To customize
the format, you must add %vsid%[9] to
the log file format string. Note that once an access log for
a resource has been created, you cannot modify its format
unless you archive it or make a new access log file for the
resource in question. You can specify logging preferences
by going to the Access Log Preferences page in the Server
Manager. Alternatively, you can manually configure directives
in obj.conf.
Enabling and configuring logging does not do much good, however,
if you never inspect the logs. Effective Webmasters inspect
their Web Server logs every day. The access log produces information
concerning requests to and responses from the Web Server.
To view the access log file, bring up the Administration Server
and select the Preferences tab. Click on the View Access Log
link and click on OK.
Finally, it is important to manage logs properly to keep
them from consuming excessive disk space. The Sun ONE Web
Server supports the schedulerd daemon that controls cron and
performs tasks such as log collection maintenance and log
file archival[10] at the time of your choice.
To start, stop or restart schedulerd, bring up the Administration
Server and select the Global Settings tab. Click on the Cron
Control link. Click on Start, Stop, or Restart to modify schedulerd.
Note that you need to restart the schedulerd control daemon
whenever you change the settings for scheduled tasks.
14. Write Common Gateway Interface
(CGI) Scripts Properly
CGI scripts provide a way to interact with Web Servers. They
extend a Web Server’s abilities by running programs
that collect user input and then return results to users.
Information can be passed to CGI scripts as standard input,
or they can obtain information through environment variables
(such as what browser is being used) that are extracted from
browser requests. They can also create pages “on the
fly,” based on data obtained during their execution.
Although extremely functional, CGI is, unfortunately, a very
basic process for handling interactions. It thus potentially
creates a large number of vulnerabilities on the server in
which it is used. These include:
Solutions that counter these and other vulnerabilities include:
- Use Perl's data tainting features whenever possible. All
variables with values supplied by users will be considered
"tainted" and will thus be barred from being able
to open files and/or make system calls. Set $ENV{PATH} to
a safe path, one of your choice, and then enable data tainting
by invoking Perl (version 5.005 or above) with the -T flag
whenever perl scripts run.
- Write CGI scripts such that they test for allowable characters
before your Web Server uses any environment variable(s).
For example, if users are to enter a phone number in a Web
page, the following string in the CGI script that receives
this input will weed out illegal characters:
$number=~/^[\d-]+{1,12}$/
|| die "Non-allowed characters in input";
The start of this string basically means that phone numbers
that are entered must conform to the specified rules. \d
means to accept numerals; the – designates that hyphens
in the phone number will also be accepted. The ^[\d-]+ means
to allow any set of permitted characters (in this case,
numerals), starting at the beginning of the line. The {1,12}
means that to be accepted, the input must be between 1 and
12 characters in length. This is length restriction is extremely
important; it prevents buffer overflows[11]
caused by excessively long input (e.g., AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA`rm
-rf \*`). The $ means that when the string comparison is
finished, you are now at the end of the line. These restrictions
help preclude the possibility of an attacker inserting commands
or meta-characters at the end of the input.
- Ensure that whenever pages on your Web Server are accessed
through links from other pages, the addresses of the referring
pages become known by including the following in your Perl
code:
$frompage=$ENV{HTTP_REFERER};
- Filter environment variables. For reasons discussed previously,
filter environment variables similarly to the way user input
is filtered.
- Drastically restrict user access to command interpreters.
The rationale for this measure was also mentioned earlier.
- Avoid calls such as system() or popen(); instead use fork(),
and then execve() to avoid calling a shell. This not only
ensures that special shell characters will not be processed,
but also precludes an extremely large number of well-known
Web Server attacks. To communicate with a spawned process,
simply manually open a pipe through which input can be passed.
- Prevent unprivileged users from being able to execute
CGI scripts in any directory. If unprivileged users can
execute CGI scripts in any directory, they may write and
then execute scripts that will purposely or accidentally
compromise your Web Server (or possibly the system on which
the Web Server runs). Limiting CGI scripts to certain directories
not only allows the Webmaster control over the content of
these directories, but it also alleviates the need to inspect
every directory to determine whether there is anything dangerous
there.
- Avoid SUID root scripts to the maximum possible extent.
In Unix and Linux platforms, limiting SUID root scripts
as much as possible lessens the probability that an unauthorized
Webuser will be able to gain root privileges.
15. Ensure that Major Vulnerabilities
Are Patched
Promptly patch major vulnerabilities in the Sun ONE Web Server,
particularly ones that result in unauthorized elevated privileges
or allow remote unauthorized access to files within the Web
Server. Patches are available here.
Information about patches can be found here.
References
Sun
Microsystems, Sun ONE Web Server 6.1 Administrator’s
Guide, 2003.
Sun
Microsystems, Security and the Sun ONE Web Server, 2003.
_____________________
Footnotes
[1] These guidelines
were developed by Gene Schultz of Berkeley Lab. Marty Gelbaum
and Anthony Lincoln of Berkeley Lab provided valuable input
and assistance.
[2] Realms (also called
“security domains”) are used by the authentication
process to verify users. Realms consist of users, elective
group mappings, and authentication logic that can verify authentication
requests.
[3] To delete a file,
the write permission is also required.
[4] You can also chroot
a directory for a virtual server by going to the Class Manager
Virtual Servers tab and the CGI Settings link.
[5] Contact the CITG group
at citg@lbl.gov to obtain a server certificate.
[6] The tlsrollback parameter
setting can protect against certain kinds of attacks against
encryption protocols such as man-in-the-middle attacks. The
recommended setting parameter (and also the default setting)
of the tlsrollback is true. Setting tlsrollback to false may
be necessary for interoperability with clients that incorrectly
implement TLS, however.
[7] You must use the
Edit Listen Sockets link (as described next) to configure
security settings if a listen socket has already created.
[8] For Netscape Navigator
6.0 check both TLS and SSL3 for Netscape Navigator 6.0. For
TLS Rollback check TLS, but disable both SSL2 and SSL3.
[9] To add %vsid% to
the log file format string, you must use a new access log
file. Bring up the Server Manager and then select the Logs
tab. Click on the Access Log Preferences link. Enter a new
log file location and filename in the Log File: text box.
Click on the Only Log: radio button. Click on the Virtual
Server ID check box.
[10] The exact tasks that
can be performed vary from server to server. Additionally,
in Windows hosts scheduling itself can be done only on a per
server basis.
[11] Go to http://www-128.ibm.com/developerworks/linux/library/l-sp4.html
for additional information concerning how to prevent buffer
overflows.
|
