Meena Vyas

Friday April 11, 2008
Intrusion detection in Sun Java System Web Server 7.0 update 2 - in experimental stages I have introduced an experimental untested intrusion detection feature
in Web Server 7.0 update 2. It is
currently an unsupported feature. Basically we can add in
server.xml a file name which contains ModSecurity ruleset. Note that this is an experimental
feature so please give me feedback about your experiences.
Additions to server.xml
Element
|
Possible
Values |
Description |
<config-file>
|
Text
|
This
element may be present at the virtual-server
level as well as at the server
level. Points to a file containing ModSecurity rules. As with all file
paths in server.xml it may be an absolute path or a relative path, in
which case it is relative to the config
directory. The file name component may contain wildcard characters to
specify multiple files within the given directory. Multiple config-file
elements may be present as well.
|
Additions to obj.conf
A new AuthTrans SAF,
secrule-config,
is introduced to control the behavior of the ModSecurity engine.
The following table describes parameters for the
secrule-config function.
| Parameter |
Description |
engine
|
(Optional) Indicates how SecRule directives are
processed at request time.
"on" indicates that the directives should be applied.
"off" indicates that the directives should not be applied.
"detection only" indicates that the
directives should be evaluated but the result of
the evaluation should not be enforced.
The default value is what is set by SecRuleEngine directive (if
any) in configuration file(s) specified by <config-file> element. If
SecRuleEngine
directive is not present, it is "off". |
| process-request-body |
(Optional) Indicates whether
request bodies are processed when evaluating SecRule directives. When
request body processing is enabled, the server will buffer the entire request body in memory, up
to the limit defined by SecRequestBodyInMemoryLimit
directive (if any) in configuration file(s) specified by <config-file> element. If
SecRequestBodyInMemoryLimit
directive is not present, it is "131072".
"on" indicates that request bodies should be processed.
"off" indicates that response bodies
should not be processed.
The default value is what is set by SecRequestBodyAccess directive
(if any) in configuration file(s) specified by <config-file> element. If
SecRequestBodyAccess
directive is not present, it is "off".
|
| process-response-body |
(Optional) Indicates whether
response bodies are
processed when evaluating SecRule
directives. When response body processing is
enabled, the server will buffer the entire response body in memory, up
to the limit defined by SecResponseBodyLimit
directive (if any) in configuration file(s) specified by <config-file> element. If
SecResponseBodyLimit
directive is not present, it is "524288".
"on" indicates that response bodies
should be processed.
"off" indicates that response bodies should not be processed.
The default value is what is set by SecResponseBodyAccess
directive (if any) in configuration file(s) specified by <config-file> directive.
If SecResponseBodyAccess
directive is not present, it is "off". |
Example
# Disable SecRule processing in
the /docs directory
<Object ppath="/docs/*">
AuthTrans fn="secrule-config"
engine="off"
</Object>
SecRuleEngine, SecRequestBodyAccess and
SecRequestBodyAccess will still
work in the files specified in
<config-file> in server.xml.
Sample :
I changed server.xml to have a new
config-file element as shown
below:
<virtual-server>
<config-file>sample.conf</config-file>
<name>test</name>
<host>...</host>
<http-listener-name>http-listener-1</http-listener-name>
</virtual-server>
and added this file in
<ws7.0u2-server-install-dir>/https-test/config
directory
$cat
sample.conf
SecRuleEngine On
# Request related
SecRequestBodyAccess On
# default limit is 128 KB (131072)
SecRequestBodyInMemoryLimit
10000
# Variables
SecRule REQUEST_HEADERS
"request_headers_match"
SecRule REQUEST_HEADERS_NAMES
"request_headers_names_match"
SecRule HTTP_xxx
"request_headers_xxx_match" "phase:1"
SecRule REQUEST_HEADERS:yyy
"request_headers_yyy_match" "phase:1"
SecRule REQUEST_HEADERS:/zzz/
"request_headers_zzz_match" "phase:1"
SecRule ARGS "args_match"
SecRule ARGS_NAMES
"args_names_match"
SecRule REQUEST_BODY
"request_body_match"
SecRule ARGS_COMBINED_SIZE "@gt
1000"
SecRule ENV "env_match"
SecRule QUERY_STRING
"query_string_match"
SecRule REQUEST_COOKIES
"request_cookies_match"
SecRule REQUEST_COOKIES_NAMES
"request_cookies_name_match"
SecRule REQUEST_HEADERS_NAMES
"x-aaaaaa.*" "rev:1,severity:2,msg:'Oops not allwed'"
#Do not match lowercase
SecDefaultAction "deny"
SecRule HTTP_User-Agent
"Internet-exprorer"
SecRule HTTP_User-Agent "Mosiac
1\.*"
SecRule REQUEST_BODY "X-AAAAAA.*"
SecRule HTTP_Referer "Powered by
Gravity Board" "id:350000,rev:1,severity:2,msg:'Gravity Board Google
Recon attempt'"
SecRule REQUEST_URI|REQUEST_BODY
"select.*from.*information_schema\.tables"
I started the server. I get this warning at the time of server start up
[11/Apr/2008:12:28:26] info (28100): CORE1116: Sun Java System Web Server 7.0U3 B04/04/2008 12:38
[11/Apr/2008:12:28:27] warning (28101): HTTP3359: An unsupported element config-file is being used. The server may not operate correctly if unsupported features are used.
[11/Apr/2008:12:28:29] info (28101): CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_12] from [Sun Microsystems Inc.]
[11/Apr/2008:12:28:43] info (28101): HTTP3072: http-listener-1: http://test.sun.com: ready to accept requests
[11/Apr/2008:12:28:43] info (28101): CORE3274: successful server startup
Now I send these two requests :
$telnet
0 1894
GET / HTTP/1.0
foo: request_headers_match
HTTP/1.1 403 Forbidden
Server:
Sun-Java-System-Web-Server/7.0
Date: Fri, 11 Apr 2008 07:01:58
GMT
Content-length: 142
Content-type: text/html
Connection: close
<HTML><HEAD><TITLE>Forbidden</TITLE></HEAD>
<BODY><H1>Forbidden</H1>
Your client is not allowed to
access the requested object.
</BODY></HTML>
$telnet
0 1894
GET / HTTP/1.0
foo: bar
HTTP/1.1 200 OK
Server:
Sun-Java-System-Web-Server/7.0
Date: Fri, 11 Apr 2008 07:02:07
GMT
Content-type: text/html
Last-modified: Fri, 04 Apr 2008
14:24:09 GMT
Content-length: 12038
Etag: "2f06-47f63a09"
Accept-ranges: bytes
Connection: close
<!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
....
</body>
</html>
The first request got denied as the header value matched with "
SecRule REQUEST_HEADERS
"request_headers_match"" rule in sample.conf as shown below :
$tail
-f ../logs/errors
[11/Apr/2008:12:31:58] security
(28166): for host 127.0.0.1 trying to GET /index.html while trying to
GET /, HTTP8005: SecRule directive in file
/export1/ws/https-test/config/ms.conf at line 7 matched returning
status code 403
Note that this
is an untested feature and may have bugs. Please let me know if you
find any.
Currently Supported ModSecurity Directives
Due to time constraints not all of the ModSecurity directives are
supported in this release. This section documents the supported subset.
Note that the supported rules are based on ModSecurity 2.0.
The terms and interfaces given below are taken from ModSecurity 2.0
documentation
http://www.modsecurity.org/documentation/modsecurity-apache/2.0.0-rc-4/modsecurity2-apache-reference.html
Some of these keywords like
VARIABLES
etc. are abstract quantities and not elements.
Directive
|
Values
|
Description |
| SecRuleEngine |
On
Off
DetectionOnly
|
server initialization
Default value is "off"
|
Directive
|
Values
|
Description |
| SecRule
|
VARIABLES
"
[@OPERATOR]
Text regular expression or parameters to pass to the operator
"
[ACTIONS] |
|
| VARIABLES |
[&!]VARIABLE[:/regular-expression/]|
[&!]VARIABLE[:name]|
[&!]VARIABLE[:regular-expression]...
|
|
&
|
should count the number of
variables in the array. |
!
|
x|!x:y examine all x but y
should
not be checked. |
|
|
concatenate variables
|
:name
|
a particular value
|
| :/regular_expression/
or :'/regular_expression/' |
matches regular expression
|
|
Values
|
Description |
VARIABLE
|
REQUEST_HEADERS |
|
| REQUEST_HEADERS_NAMES |
|
REQUEST_HEADERS:yyy
or REQUEST_HEADERS:/yyy/ |
Where yyy is any applicable
request header name.
|
| ARGS |
Contains request body if SecRequestBodyAccess
is set to on.
|
ARGS_NAMES
|
|
| ARGS_COMBINED_SIZE |
|
| AUTH_TYPE |
|
ENV
|
|
QUERY_STRING
|
|
| HTTP_yyy |
|
| TIME,
TIME_EPOCH, TIME_DAY, TIME_HOUR, TIME_MIN, TIME_SEC,
TIME_WDAY, TIME_MON, TIME_YEAR |
|
| REMOTE_HOST,
REMOTE_PORT, REMOTE_USER,
REMOTE_ADDRESS |
|
| PATH_INFO |
|
| SERVER_NAME,
SERVER_PORT, SERVER_ADDR |
|
SCRIPT_BASENAME,
SCRIPT_FILENAME
|
|
| REQUEST_COOKIES |
|
| REQUEST_COOKIES_NAMES |
|
REQUEST_FILENAME
|
|
| REQUEST_BASENAME |
|
REQUEST_BODY
|
|
| REQUEST_LINE |
|
| REQUEST_METHOD |
|
| REQUEST_PROTOCOL |
|
| REQUEST_URI,
REQUEST_URI_RAW |
|
| RESPONSE_BODY |
|
| RESPONSE_STATUS |
|
RESPONSE_HEADERS
|
|
| RESPONSE_HEADERS_NAMES |
|
RESPONSE_PROTOCOL
|
|
|
Values
|
| OPERATOR |
rx
|
eq
|
ge
|
gt
|
le
|
lt
|
validateByteRange
|
|
Values
|
Description |
ACTIONS
|
ACTION[:xxx],
ACTION[:xxx] ...
|
|
|
Values
|
ACTION
|
allow |
msg
|
id
|
rev
|
severity
|
log
|
deny
|
status
|
phase
|
t
|
skip
|
chain
|
|
Values
|
Description |
phase
|
[1..4]
|
phase:1 - Request headers stage
phase:2 - Request body stage
phase:3 - Response headers stage
phase:4 - Response body stage
Default
value is phase:2
Note that operations on "phase:5 (Logging stage)" are not supported. If
encountered, these are ignored and a log message is recorded.
|
|
Values
|
Description |
t
|
lowercase
|
Transformation functions to perform
on the variables before operator
is executed (this includes request body) |
urlDecode
|
| none |
| compressWhitespace |
removeWhitespace
|
| replaceNulls |
| removeNulls |
Directive
|
Values
|
Description |
| SecDefaultAction |
ACTIONS
|
For a SecRule, if the previous SecDefaultAction directive is
present, those actions takes into effect.
If none of these SecDefaultAction
directives are present before a SecRule
(in that file or files loaded before it), default SecDefaultAction
directive with
ACTIONS
"log,deny,status:403,phase:2,t:replaceNulls,t:compressWhitespace,t:lowercase"
is internally added.
|
For the following directives, in case the multiple directives are
present (in one or multiple files), last directive's value takes the
precedence.
| Directive
|
Values
|
Description |
SecRequestBodyAccess
|
On
Off
|
Whether the server should parse
request body or not.
Default value is "off"
|
| Directive
|
Values
|
Description |
| SecRequestBodyInMemoryLimit |
integer
|
Configures the maximum request body size server will store in
memory. By default the limit is 128 KB (131072)
|
| Directive
|
Values
|
Description |
| SecResponseBodyAccess |
On
Off
|
Whether the server should parse
response body or not. Default value is "off" |
| Directive
|
Values
|
Description |
| SecResponseBodyLimit |
integer
|
Configures the maximum response body size that will be
accepted for buffering. Anything over this limit will be rejected with
status code 500 Internal Server Error. This setting will not affect the
responses with MIME types that are not marked for buffering. By default
this limit is configured to 512 KB. (524288)
|
| Directive
|
Values
|
Description |
SecResponseBodyMimeType
|
strings
|
Configures which MIME types are
to be considered for response body buffering. The default value is text/plain text/html.
|
| Directive
|
Values
|
Description |
| SecResponseBodyMimeTypesClear
|
-
|
Clears the list of MIME types considered for response body
buffering, allowing to start populating the list from scratch. |
Posted by meena
( Apr 11 2008, 12:49:41 PM IST )
Permalink

Tuesday February 05, 2008
Using HTTP compression to speed up content delivery in Sun Java System Web Server 7.0 update 2
Using HTTP compression to speed up content delivery in Sun Java
System Web Server 7.0 update 2
If you are looking for faster web page downloads, you can use HTTP
compression feature which compresses your content to speed it up. It is especially beneficial for
low bandwidth connections. This also reduces the number of bytes
transferred and improves the overall server performance.
How it Works
Browsers that support compressed content send an
Accept-encoding header with
value
gzip, deflate.
Our Web Server sees the header and chooses to provide compressed
content, and sends
Content-encoding:
gzip response header. The browser on seeing this header tries to
decompress the content and renders it.
Now the question is how to enable HTTP compression feature can be
configured in obj.conf. Let me explain that in detail
in this blog.
READ MORE >>>>>>
[
Read More]
Posted by meena
( Feb 05 2008, 02:24:29 PM IST )
Permalink

Wednesday September 19, 2007
Using builtin hardware accelerators of Niagara 1 (Sun Fire T 2000) server with SSL enabled Sun Java System Web Server 7.0 instance
In my previous blog
I talked about SCF framework and Sun Java System Web Server 7.0 in general. This time
I tried to make use of builtin hardware accelerators of Niagara 1 (Sun
Fire T 2000) server with my SSL enabled Sun Java System Web Server 7.0 U2
instance. My blog is an attempt to show how easy it is to do so.
READ MORE DETAILS>>>
[Read More]
Posted by meena
( Sep 19 2007, 01:31:20 PM IST )
Permalink

Monday July 23, 2007
Configuring reverse proxy in Sun Java System Web Server 7.0 when origin server is SSL enabled
Configuring reverse proxy in Sun Java System Web Server 7.0 when origin server is SSL
enabled
In this blog I have tried to set up a
scenario where a non SSL Sun Java System Web Server 7.0 tries to
connect to origin server which is SSL enabled.
...
Settings in Web Server 7.0 instance
Lets say we want to forward all
requests to /xyz to the origin server. Go the Web Server instance config directory and modify the obj.conf as given below.
...
Troubleshooting
In case we get a Gateway Timeout error
and in error logs we see some error like
[23/Jul/2007:16:44:11] failure
(27927): for host .... trying to GET ...., service-http reports:
HTTP7758: error sending request
(SEC_ERROR_UNTRUSTED_ISSUER: Client certificate is signed by an
untrusted issuer.)
We get this error because the origin server's certificate was not issued by a trusted CA. It means we need to export CA certificate of the origin server instance and import it into Web Server instance.
...
READ MORE
[
Read More]
Posted by meena
( Jul 23 2007, 07:13:46 PM IST )
Permalink

Thursday March 15, 2007
Troubleshooting memory leaks and memory corruptions in Sun Java System Web Server 7.0
Troubleshooting memory leaks and memory corruptions in Sun Java System Web Server 7.0
In this blog I am trying to show how to use libumem and watchmalloc to find more information about memory leaks and memory corruptions in Sun Java System Web Server 7.0.
...
READ MORE >>>>
[
Read More]
Posted by meena
( Mar 15 2007, 12:53:56 PM IST )
Permalink

Wednesday March 14, 2007
Troubleshooting Web Server crashes : enabling core dumps
Troubleshooting Web Server crashes : enabling core dumps
I get a lot of questions regarding what to do when Web Server instance crashes as shown by error logs and you do not find the core file.
The core file will be dumped in the Web Server instance's config directory. For example, if the Web Server is installed in
/opt/SUNWwbsvr directory, core file will be
/opt/SUNWwbsvr/https-hostname/config/core.
If you are using SSL, core dumps will be disabled by default. You can force them on by setting the
SSL_DUMP environment variable before starting Web Server:
$ SSL_DUMP=1
$ export SSL_DUMP
$ ./start
Check
coreadm(1M) and
ulimit(1) to see if Solaris will allow processes to dump core. Use the
pstack(1M) command to obtain a stack trace. You can use the same
coreadm (core file administration) command to set appropriate values.
$coreadm
global core file pattern:
global core file content: default
init core file pattern: core.%p
initcore file content: default
global core dumps: disabled
per-process core dumps: enabled
global setid core dumps: disabled
per-process setid core dumps: disabled
global core dump logging: disabled
Note that I have set core file pattern to core.%p instead of the usual core . If a process with pid
lets say 1000 dumps core, it will generate a core file with name core.1000 to avoid overriding in case the server dumps
multiple core files. But this is not necessary.
If your Operating System is Linux, make sure that you set
ulimit to
unlimited
$ulimit -c unlimited
To get core dumps on Windows, first make drwatson as a default debugger:
C:\WINDOWS\system32>drwtsn32.exe -i
To change various settings of this drwatson,
C:\WINDOWS\system32>drwtsn32.exe
This opens a window where you can specify where to dump the core.
To set back the default debugger to MSVC, change registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug to
"C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin\msdev.exe" -p %ld -e %ld
Set
Auto to
0.
Set
UserDebuggerHotKey to
0.
Posted by meena
( Mar 14 2007, 12:53:11 PM IST )
Permalink

Wednesday March 07, 2007
Denial of Service (DoS) Prevention By Request Timeout in Sun Java System Web Server 7.0
Denial of Service (Dos) Prevention By Request Timeout in Sun Java System Web Server 7.0
Denial of Service (DoS) Prevention By Request Timeout in Sun Java System Web Server 7.0
Check out the new improvements we made in Sun Java System Web Server 7.0. In this blog I will talk about Denial Of Service (DoS) Prevention "Request Timeout" enhancements.
We have introduced two more timeouts in the server.xml's
<http> element in addition to the existing
<io-timeout>. They are
<request-header-timeout>
and
<request-body-timeout>.
If you are a Web Server Administrator and you want to limit users to be sending all request headers in the first 10 minutes of the connection and request body in the next one hour, you can set these two parameters in server.xml like
...
<http> ...
<request-header-timeout>600</request-header-timeout>
<request-body-timeout>3600</request-body-timeout>
</http>
...
All other connections which last longer will be disconnected by the
server automatically.
Posted by meena
( Mar 07 2007, 12:20:34 PM IST )
Permalink

Monday February 26, 2007
Directory listing in Sun Java System Web Server 7.0
Directory listing in Sun Java System Web Server 7.0
Directory listing in Sun Java System Web Server 7.0
Been getting a lot of questions about directory listing in Sun Java System
Web Server 7.0
I have setup a Sun Java System Web Sever 7.0. I am not able see directory contents. I get a popup saying "Authentication Required". Under "Content Handling"->"General"->"Directory Listing", I tried setting "Listing Type" to 'Fancy' & 'Simple'. But that did not help (I saved and re-deployed the server instance).
Here is the solution. Check in obj.conf configuration file if "index-common" service SAF is present:
Service method="(GET|HEAD)" type="magnus-internal/directory" fn="index-common"
Directory listing is not enabled by default. If you look at the default ACL file default.acl, (assuming you do not have any other other VS specific ACL file)
version 3.0;
acl "default";
authenticate (user, group) {
prompt = "Sun Java System Web Server";
};
allow (read, execute, info) user = "anyone";
allow (list, write, delete) user = "all";
That shows
"list" right is allowed to
"all" (authenticated users only). And for directory listing, you need "list" rights. That means only authenticated users can see directory lists.
You can move this
"list" right to
"anyone" so that even
unauthenticated users can see the directory lists.
So here is what the changed ACEs should look like :
allow (read, execute, info, list) user = "anyone";
allow (write, delete) user = "all";
Two more minor tips I would like to add
1. If you want to change the width of the columns of filename, last modified time, size, description in directory listing, add "cindex-init" directive in magnus.conf. For example
Init fn="cindex-init" widths="50,5,5,20"
2. If you want to change the directory listing to "simple" style where you will only see the list of filenames, you can change "index-common" to "index-simple" as shown below
Service method="(GET|HEAD)" type="magnus-internal/directory" fn="index-simple"
Posted by meena
( Feb 26 2007, 01:25:10 PM IST )
Permalink

Saturday January 20, 2007
Creating Authentication Databases in Sun Java System Web Server 7.0
Creating Authentication Databases in Sun Java System Web Server 7.0
I have tried out creating different authentication databases (keyfile, digestfile, LDAP, PAM) via administration CLIs in Sun Java System Web Server 7.0.
...
I created a file authentication database of type "keyfile" in config "test" and in virtual server "test".
wadm>
create-file-authdb
--vs=test --config=test --path=/space/mykeyfile mykeyfile
CLI201
Command 'create-file-authdb' ran successfully
Then created a file authentication database of type "digest", added "--syntax=digestfile" in the above command.
...
>>> READ MORE >>>
[
Read More]
Posted by meena
( Jan 20 2007, 03:42:36 PM IST )
Permalink

Saturday December 02, 2006
Migrating Apache After reading my blog about "Migrating JKS Keystore Entries to NSS DB in Sun Java System Web Server 7.0", somebody asked me how to migrate Apache certificates to Sun Java System Web Server 7.0. I found these nice blogs Nelson has written about Apache Migration.
Posted by meena
( Dec 02 2006, 01:48:19 PM IST )
Permalink

Monday October 30, 2006
Disabling TRACE in Sun Java System Web Server 7.0 In Sun Java System Web Server 7.0 or Sun ONE Web Server 6.1, comment the TRACE service in obj.conf.
#Service method="TRACE" fn="service-trace"
For releases prior to Sun ONE Web Server 6.1:
<Client method="TRACE">
AuthTrans fn="set-variable"
remove-headers="transfer-encoding"
set-headers="content-length: -1"
error="501"
</Client>
It is a perception that Sun Java System Web Server (Web Server) is somehow vulnerable with these methods.
These methods (except for TRACE) are NOT enabled by default in the Web Server. The fact that OPTIONS request lists these methods doesn't mean they could be exploited.
Web Server responds to the HTTP OPTIONS method by reporting the methods understood. It should be noted that indication that a method is understood, however, is no guarantee that a method is permitted or will be executed.
By default Web Server blocks all "privileged" HTTP methods behind the Access Control Lists (ACL) system. Attempts to invoke the methods will be responded to with an HTTP 401 error code (Unauthorized) requesting credentials from the User-Agent. If valid credentials are provided, or if the default ACL is disabled, Web Server will respond with an HTTP 405 error code (Method Not Allowed).
You can also set it as the first ACE in the default.acl :
deny absolute (http_trace, http_put, http_delete, http_move, http_mkdir, http_rmdir)
user="anyone";
Related Links :
Posted by meena
( Oct 30 2006, 12:55:04 PM IST )
Permalink

Friday September 29, 2006
Migrating JKS Keystore Entries to NSS datbase in Sun Java System Web Server 7.0 or 6.x
Migrating JKS Keystore Entries to NSS database in Sun Java System Web Server 7.0 or 6.x
I installed Sun Java System Web Server
7.0 in
<server-installation>directory and started Administration server.
...
Now I used
wadm to run Administration CLIs
...
I run
migrate-jks-keycert CLI
wadm>
migrate-jks-keycert
--config=test --keystore=
/tmp/my-jks-key-store.jks
Please
enter keystore-password> storepass
Please enter key-password>
keypass
Please enter certdb-password> nsspass
CLI201 Command
"migrate-jks-keycert" ran successful.
Read More >>>>
[
Read More]
Posted by meena
( Sep 29 2006, 11:52:17 AM IST )
Permalink

Thursday September 21, 2006
Solaris Cryptographic Framework and Sun Java System Web Server 7.0
Solaris Cryptographic Framework and Sun Java System Web Server 7.0
Here are my initial experiments to use
external PKCS#11 security module Solaris Cryptographic
Framework in Sun Java System Web Server 7.0.
Initial steps
First I removed .sunw
directory
$rm -rf
$HOME/.sunw
Then I initialized password/pin
$pktool
setpin
Enter new
PIN:typed-my-password-here
Re-enter
new PIN:typed-my-password-here
Then disabled the following 5
mechanisms
#cryptoadm
disable provider=/usr/lib/security/\$ISA/pkcs11_kernel.so
mechanism=
Read MORE >>>>>
Read my next blog
Using builtin hardware accelerators of Niagara 1 (Sun Fire T 2000) server with SSL enabled Sun Java System Web Server 7.0 instance
[
Read More]
Posted by meena
( Sep 21 2006, 02:06:49 PM IST )
Permalink

Tuesday June 13, 2006
Cross Site Scripting Prevention in Sun Java System Web Server 7.0
Cross Site Scripting Prevention in Sun Java System Web Server 7.0
Check out the new improvements we
made in
Sun Java
System Web Server 7.0 Technology Preview 3. It can be downloaded for
free from
here.
In this blog I will talk about Cross Site Scripting (XSS) prevention.
Obj.conf now supports a lot of features which allows you to use it a
lot like a programming language, which allows us to configure in our
WebServer features similar to in ModSecurity Apache Module.
The main method of preventing Cross Site Scripting (XSS) is through entity encoding, using entities
such as "
<".
We now have a introduced a native input stage filter based on sed which can do XSS filtering.
Read More>>>
[
Read More]
Posted by meena
( Jun 13 2006, 11:49:12 AM IST )
Permalink

Friday June 09, 2006
Dynamic compression of static files in Sun Java System Web Server 7.0
Dynamic compression of static files in Sun Java System Web Server 7.0
Check out the new cool features in
Sun Java
System Web Server 7.0 Technology Preview which can be downloaded for
free from
here.
In this blog I will talk about dynamic compression of static files.
We have also implemented caching of compressed data
for static files. We have added a new service function
"compress-file" which will
compress static files (if the compressed file doesn't exist) and serves
it from the cache if the compressed version already exists.
Lets say if I want to create .gz files on the fly for static
files, all I have to do is to modify obj.conf as shown below.
READ MORE>>>
[
Read More]
Posted by meena
( Jun 09 2006, 12:28:26 PM IST )
Permalink

Tuesday May 16, 2006
New Feature WebDAV Access Control Protocol In Sun Java System Web Server 7.0
New Feature WebDAV Access Control Protocol In Sun Java System Web Server 7.0
The Sun Java System Web Server 7.0 Technology Preview was released today! There's a whole bunch of new stuff in 7.0, and you can
use
it free of charge.
WebDAV and WebDAV Access Control Protocol support in Sun Java System Web Server 7.0
Sun Java System Web Server 7.0 now
- Conforms to WebDAV protocol as defined by the RFC
2518.
- Supports the following HTTP methods GET, HEAD, OPTIONS, PUT, LOCK, UNLOCK,
MKCOL, COPY, MOVE PROPPATCH, DELETE, PROPFIND.
- Conforms to WebDAV Access
Control Protocol as defined by
the RFC 3744.
- Also supports ACL,
REPORT(DAV:acl-principal-prop-set, DAV:principal-match,
DAV:expand-property), PROPFIND (DAV:acl and
DAV:current-user-privilege-set property).
- Has finer access rights like dav:all, dav:read, dav:read-acl,
dav:read-current-user-privilege-set, dav:write, dav:write-acl,
dav:write-properties, dav:write-content, dav:bind, dav:unbind,
dav:unlock.
Read More>>>>
[
Read More]
Posted by meena
( May 16 2006, 11:22:27 PM IST )
Permalink
Configuring WebDAV in Sun Java System Web Server 7.0
Configuring WebDAV in Sun Java System Web Server 7.0
Download Sun Java System Web Server 7.0 Technology Preview absolutely free from here.
Also check out my next blog about WebDAV Access Control Protocol(RFC 3744) support in Sun Java System Web Server 7.0.
Overview
WebDAV stands for "Web-based Distributed Authoring and Versioning". It
is a set of extensions to the HTTP protocol which allows users to
collaboratively edit and manage files on remote web servers. Sun Java
System Web Server 7.0 conforms to WebDAV protocol as defined by the RFC
2518 and the WebDAV Access Control Protocol specification as defined by
the RFC 3744.
In this article I will describe how to configure WebDAV in Sun Java System Web Server 7.0 via Administration CLI.
Read More>>
[
Read More]
Posted by meena
( May 16 2006, 11:17:56 PM IST )
Permalink
Configuring Reverse Proxy in Sun Java System Web Server 7.0 Technology Preview
Configuring Reverse Proxy in Sun Java System Web Server 7.0 Technology Preview
Sun Java System Web Server 7.0 Technology Preview is now avaliable for FREE and can be downloaded from
here.
Introduction
A reverse proxy is a proxy that appears to be a web server (origin server) to clients but in reality forwards the requests it receives to one or more origin servers. Because a reverse proxy presents itself as an origin server, clients do not need to be configured to use a reverse proxy. By configuring a given reverse proxy to forward requests to multiple similarly configured origin servers, a reverse proxy can operate as an application level software load balancer. In a typical deployment one or more reverse proxies will be deployed between the browsers and the origin servers.
In this article I will descirbe how to configure reverse proxy in Sun Java System Web Server 7.0 via Administration CLI.
Read More >>
[
Read More]
Posted by meena
( May 16 2006, 11:15:12 PM IST )
Permalink
Access Control In Sun Java System Web Server 7.0 - II
Access Control In Sun Java
System Web Server 7.0 -II
After
my first blog about Access Control in general, let me try to talk about some more ACL related topics.
Access Rights in Access Control Lists in Sun Java System Web Server 7.0
Access rights that can be used to set access control in ACL file in Sun Java System Web Server 7.0 are
- all
- read
- execute
- info
- write
- list
- delete
- http_<method>
- dav:read-acl
- dav:read-current-user-privilege-set
Read More >>
[
Read More]
Posted by meena
( May 16 2006, 11:11:46 PM IST )
Permalink
Access Control In Sun Java System Web Server 7.0
Access Control In Sun Java System Web Server 7.0
Sun Java System Web Server 7.0 Technology Preview is released and is FREE download it from
here.
What Is Access Control?
Access control allows us to determine and manage
- Who (subject) can access the resources on our web site
- Which resources (like files or directories) they can access
- Which operations can they perform (like creating a file, POST-ing
contents to the server).
We can allow or deny
access based on:
- Who is making the request (for example, user or group using user, group attributes).
- Where the request is coming from (for example, host or IP using ip, dns attributes).
Read More >>
[
Read More]
Posted by meena
( May 16 2006, 11:09:44 PM IST )
Permalink