1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<meta NAME="Author" CONTENT="Stefano Mazzocchi">
<title>Installation and Configuration</title>
</head>
<body BGCOLOR="#FFFFFF">
<p align="center"><a href="http://java.apache.org/" target="_top"><img SRC="../images/java-apache-project.gif" BORDER="0" WIDTH="609"
HEIGHT="100" ALT="The Java Apache Project"></a></p>
<h1 align="center">How to secure your servlet environment</h1>
<h3 align="left">Introduction</h3>
<p align="left">In this section, you will learn how to secure your servlet engine in a
variety of different situations. This howto is an introduction to the security issues
involved with Apache JServ.</p>
<h3 align="left">External security</h3>
<p align="left">Apache JServ 1.0 has introduced important enhancements on the
communication protocol to reduce the risks of untrusted servlet execution. Let's make an
example so that you get the idea of the problem. Let us suppose you have a free-form SQL
query servlets connected to your precious database. This servlet is for remote
administration and database debugging purposes and it's secured by any means on the web
server side.</p>
<p align="left">If no security restrictions were available on the servlet engine side, a
wise and knowledge attacker might request that servlet directly to the servlet engine,
thus bypassing web server security. This is called an external attack.</p>
<p align="left">To prevent external attacks Apache JServ 1.0 introduced new powerful
security restrictions: an IP filter for incoming connections and an MD5-based connection
authentication scheme.</p>
<h3 align="left">IP filtering</h3>
<p align="left">The most simple and effective way of reducing the risk of external attacks
is to filter incoming requests based on the IP address of the client. Note that this
doesn't affect the wide audience of the web server because only web servers should be
allow to connect to the servlet engine. For this reason, to enable connections from a
particular IP address you must specify it in the allowed list in the main Apache JServ
configuration file.</p>
<p align="left">For example, if you have two web servers that make requests using
194.39.283.233 and 194.39.283.234 and wish to restrict the servlet requests only from
those addresses you add the following line to your <em>jserv.properties</em> file</p>
<blockquote>
<div align="left"><pre>security.allowedAddresses=194.39.283.233,194.39.283.234</pre>
</div>
</blockquote>
<p align="left">With this filter enabled, any connection coming on the port Apache JServ
is listening to from an IP address not contained in the list, is automatically ignored.</p>
<h3 align="left">Connection authentication</h3>
<p align="left">In the rare cases where IP filtering is not enough, for example when
untrusted users may generate requests from the allowed IP address, authentication
connection can be used to reduce to a minimum the chance of external attack. To do this,
both the web server and the servlet engine must have a binary copy of the same file, any
file, that is called <em>secret key</em>.</p>
<p align="left">This file may have any format and any length (could even be an image!),
but we suggest you to create your own text file monkey-typing around a hundred bytes.
After a few dozens of bytes, the security improvement is negligible while the time taken
by the authentication procedure is linear with the secret key length. For this reason
there is very little need for long secret keys.</p>
<p align="left">Note: your security is strictly related to that secret key file. Anybody
that can guess or recreate your secret key is a potential external attacker if his
requests come from the correct IP addresses. It is not needed to suggest you to protect
your secret key files and make them not readable or writable to untrusted users.</p>
<p align="left">To enable the authentication on the servlet engine side you should add
these two lines to your <em>jserv.properties</em> file</p>
<blockquote>
<div align="left"><pre>security.authentication=true
security.secretKey=/etc/jserv/jserv.secret.key</pre>
</div>
</blockquote>
<p align="left">Then you have to enable authentication on every web server that connects
to that servlet engine adding this line to your <em>httpd.conf</em> files</p>
<blockquote>
<div align="left"><pre>ApJServSecretKey /etc/jserv/jserv.secret.key</pre>
</div>
</blockquote>
<p align="left">Make sure the two secret key files are even the same or the exact binary
copy, and both the web server and the servlet engine have permissions to read them.</p>
<h3 align="left">Internal security</h3>
<p align="left">While external security is the matter of restricting untrusted servlet
execution, internal security deals with securing systems from dangerous servlet behavior.
If you build your own servlets or have full control over them (having the source code) you
don't need any more internal security. Things get different if you use precompiled
servlets you don't trust like in the case of ISP's providing servlet environments for
third parties.</p>
<p align="left">Like the ability of running CGI with different UID/GID, on possible
solution for internal security is to have different instances of the servlet engine
running with different UID/GID. This allows complete separation of the servlets served by
the different servlet engine instances.</p>
<p align="left">Another possibility, that will be implemented in the future, is the use of
more complex Java security managers to protect system resources from unwanted servlet
behavior. This will be implemented in future releases.</p>
<p align="center"><font SIZE="-1">Copyright (c) 1997-99 <a HREF="http://java.apache.org/"
target="_top">The Java Apache Project</a>.<br>
$Id: howto.security.html,v 1.6 2000/05/19 23:29:02 admin Exp $<br>
All rights reserved.</font></p>
</body>
</html>
|