Servertec Security
Content
Introduction
Release Notes
Features
FAQs
Requirements
Installation
How To
Change Log
Future Plans
Knowledge Base
Documentation
Conventions
Command Line
Administrator
Localization
Programming
Security
Performance
Deployment
Server API
Servlet / JSP API
Xerces API
CGI
SSI
Servlets
Config Files
Log Files
Classes
Directory Tree
Examples
Legal
Contact Us

 

General
  • Limit what software is installed and running to what is needed on computers that are accessible over the Internet.
  • Limit who has access to computers accessible over the Internet.
  • Limit what computers accessible over the Internet have access to.
  • Do not store sensitive content on computers that are accessible over the Internet.
  • Do not publicly disclose servers or network infrastructure.
  • Be vigilant at all times and assume that security has been compromised.
  • Periodically and as random as possible take down a server at a time and re-install from scratch operating system, Java, Servertec Internet Server and any other software from master image assigning new usernames and passwords.
  • Use separate subnets for servers accessible over the Internet from computers used for development, testing and in house use.
  • Run Web Server(s), Application Server(s) and Database Server(s) on a separate dedicated machines.
  • Perform backups on a daily basis.

    Passwords

  • Immediately change default passwords.
  • Change password periodically, randomly and as frequently as possible.
  • When choosing a username and password do not use obvious words or easily guessed terms. Use at least 8 characters and use a mix of lower and upper case letters, numbers and symbols.
  • Avoid giving out or witting down usernames and passwords.
  • Maintain an encrypted list of all usernames and passwords in a highly secure safe.
  • Maintain a list of who has access to what passwords and when someone leaves change all the passwords that this individual had accessed to.

    Firewalls

  • Always run behind a Firewall that has all unused ports blocked.
  • Run content delivery Web Servers outside of the Firewall and content generation Application Servers and Database Servers inside the firewall. That way if security has been compromised access is limited.
  • Run two sets of servers, deployment servers outside the Firewall and another synchronized master servers inside. That way if security has been compromised the masters servers will hopefully remain intact and secure.

    Software

  • Install and run only the software that is needed.
  • Test all new software and software updates for security weaknesses before deploying.
  • Immediately apply security patches.
  • Install, use and frequently update Anti-virus software.
  • Install and use software that monitors the file system for changes.
  • If possible examine source code for all software in use for backdoors and security holes.

    Operating System

  • Install only the services/features/protocols that are needed.
  • Limit what is defined on the PATH variables to what is needed.
  • Delete all unnecessary accounts.
  • Immediately change default passwords.
  • Password protect all accounts.
  • If possible remove root and administrator accounts.
  • If possible remove telnet, ftp, mail, print spooler and other services that are popular backdoors.
  • If possible enable journally and auditing.

    Database Engines

  • Install only the services/features/protocols that are needed.
  • Immediately change default passwords.
  • Password protect all databases.
  • If possible enable journally and auditing.

    Software Development

  • Programmers should install a security manager and customize securty policy for their applications.
  • Do not hard code IP address into content and into code. Sometimes when under Denial of Service (DOS) attack changing the DNS mapping to under IP address masks the problem if the attacker continues to access the old IP address.

    Servertec Internet Server Configuration

  • Change the Administrator's default Username and Password using the Administrator from the Server form change the Username and Password.
  • If the server does not need to be remotely administered then using the Administrator from the Server form disable Remote Administration.
  • If using HTTP/1.1 and Keep-Alive is supported then using the Administrator from the Socket form enable Keep Alive Enabled.
  • If Keep Alive Enabled is enabled in the Socket form from the Administrator then set Keep Alive Requests and Keep Alive Timeout in the Socket form using the Administrator to appropriate values to prevent Denial of Service (DOS) attacks.
  • If possible set Socket Timeout to a value other than -1 in the Socket form using the Administrator. Setting Socket Timeout to -1 opens the server to Denial of Service (DOS) attacks. Setting Socket Timeout too large opens the server to Denial of Service (DOS) attacks, but setting it too small may result in valid requests timing out.
  • If possible using the Administrator from the Server form enable Security Enabled and protect resources.
  • If Servlet Chaining is not required then using the Administrator from the Server form disable Servlet Chaining.
  • If possible set Server Socket Timeout to a value other than -1 in the Socket form using the Administrator. Setting Server Socket Timeout to -1 opens the server to Denial of Service (DOS) attacks.
  • If possible disable Wait On Full in the Socket form using the Administrator. Enabling Wait On Full opens the server to to Denial of Service (DOS) attacks.
  • If possible run the server on a non-standard port number by changing the Port number in the Socket form using the Administrator.
  • Setting Socket Source to Queue opens the server to Denial of Service (DOS) attacks.
  • If possible set Maximum Header Length to a value other than -1 in the Server form using the Administrator. Setting Maximum Header Length to -1 opens the server to Denial of Service (DOS) attacks. Setting Maximum Header Length too large opens the server to Denial of Service (DOS) attacks, but setting it too small may result in valid requests being rejected.
  • If possible set Maximum Header Count to a value other than -1 in the Server form using the Administrator. Setting Maximum Header Count to -1 opens the server to Denial of Service (DOS) attacks. Setting Maximum Header Count too large opens the server to Denial of Service (DOS) attacks, but setting it too small may result in valid requests being rejected.
  • If possible set Maximum Content Length to a value other than -1 in the Server form using the Administrator. Setting Maximum Content Length to -1 opens the server to Denial of Service (DOS) attacks. Setting Maximum Content Length too large opens the server to Denial of Service (DOS) attacks, but setting it too small may result in valid requests being rejected.
  • If possible set Maximum Client Requests to a value other than -1 in the Server form using the Administrator. Setting Maximum Client Requests to -1 opens the server to Denial of Service (DOS) attacks. Setting Maximum Client Requests too large opens the server to Denial of Service (DOS) attacks, but setting it too small may result in valid requests being rejected.
  • If CGI is not being used and SSI is not using CGI then using the Administrator from the Aliases form remove /cgi-bin, from Servlets form remove CgiServlet and from Server form disable Shell Access.
  • If SSI is not being used then using the Administrator from the Aliases form remove .shtml and from Servlets form remove SSIncludeServlet.
  • If access to directory listings are not required then using the Administrator from the Servlet form set directory_access=n for FileServlet.
  • Using the Administrator from Aliases form remove all unused aliases.
  • Using the Administrator from Servlets form remove all unused servlets.
  • If servlets are always defined and aliases and /servlet is not used to automatically access servlets without prior configuration then using Administrator from Aliases form remove /servlet and from Servlets from remove InvokerServlet.
  • If Servlet tag is not being used then using the Administrator from the Aliases form remove .ssi and from the Servlets form remove ServletTagServlet.
  • If Servlet tags with SSI is not being used then using the Administrator from the Aliases form remove .xssi.
  • If the server will not be stopped or restarted from the MS-DOS Prompt or from the Linux/Solaris/Unix shell prompt then using the Administrator from the Aliases form remove /command and from the Servlets form remove CommandServlet.
  • If the server is not running in a workgroup and the Administrator is not being used then using the Administrator from the Aliases form remove /status and from the Servlets form remove StatusServlet.
  • If only servlets are being used and files are not being served then using the Administrator from the the Aliases form remove / and from the Servlets form remove FileServlet.
  • Using the Administrator from the Pools form remove any unused connection pools.
  • Using the Administrator from the Realms form remove all unused realms.
  • Using the Administrator from the Resources form remove all unused resources.
  • Using the Administrator from the Users form remove all unused users.
  • Using the Administrator from the Groups form remove all unused groups.
  • Using the Administrator from the Computers form remove all unused computers.
  • Using the Administrator from the Access Rights form remove all unused access rights.
  • Using the Administrator from the ACLs form remove all unused access control lists.
  • Using the Administrator from the Logger form remove any unused loggers.
  • Using the Administrator remove all unused servlet contexts from the Aliases form and from the Contexts form.
  • If possible limit the IP addresses that the server listens to by specifying a single IP address using the Administrator from the Server form.
  • If possible run the server from a login that does not have root or Administrator access.
  • If possible remove the Administrator. Using the Administrator from the Aliases form remove /admin.html and from the Servlets form remove AdminServlet.
  • If possible log access, errors and events by enabling Log Access, Log Events and Logs Errors from the Logger form using the Administrator.
  • Monitor the server's log files regularly for any suspicious activity.
  • If possible check session IP addresses by enabling Check IP Address from the Session form using the Administrator.
  • If possible check the session's source by enabling Check Session Source from the Session form using the Administrator.
  • If possible protect access to all files and servlets by defining resources for them using the Administrator in the Resources form and by defining access control lists for them in the ACLs form.
  • If possible define all computers that will be able to access files and resources by defining them using the Administrator from the Computers form, defining resources for them in the Resources form and by defining access control lists for them in the ACLs form.
  • If possible define all users that will be able to access files and resources by defining them using the Administrator from the Users form, defining resources for them in the Resources form and by defining access control lists for them in the ACLs form.

    Web Resources

  • The World Wide Web Consortium (W3C) World Wide Web Security FAQ
  • Beyond-Security's SecuriTream.com
  • Network Working Group Site Security Handbook
  • RedHat Security
  • Microsoft Security
  • Netsurfer Focus on Computer and Network Security
  • JavaTM Security

    Books

  • Web Security & Commerce by Simson Garfinkel with Gene Spafford
  • Web Security: A Step-by-Step Reference Guide by Lincoln D. Stein
  • Building Internet Firewalls, 2nd Edition by Elizabeth D. Zwicky, et al

  • Practical UNIX & Internet Security, 2nd Edition by Simson Garfinkel & Gene Spafford
  • Solaris Security by Peter H. Gregory
  • Designing Secure Web-Based Applications for Microsoft(r) Windows(r) 2000 by Michael Howard
  • Securing Windows NT/2000 Servers for the Internet by Stefan Norberg, Deborah Russell

  • Java Security, 2nd Edition by Scott Oaks
  • Java Security Handbook by Jamie Jaworski, Paul Perrone

  • Oracle Security by Marlene Theriault & William Heney

    Notes

    Some of the above suggestions may have a negative impact on performance, may limit functionality and may add to operating costs.

    Disclaimers

    The above sections on how to secure Servertec Internet Server are by no means complete, ordered or definitive and should only be used as a starting point.

    Web Resources or Books listed are not to be taken as an endoursement or recommendation and are by no means complete, ordered or definitive and should only be used as a starting point.

  •  top of page
    Copyright © 1998-2005 Servertec. All rights reserved.
    Privacy Statement.
    Last Modified: Sun Sep 04 14:57:18 EDT 2005