Monthly Archive: July 2011

How and Why we need to SECURE our Web Server

Introduction: Over the year’s internet and the internet based applications had revolutioned our life. They had created many new global business opportunities for enterprises conducting online business. However, the security risks associated with conducting e-business have resulted in security becoming a major factor for online success or failure.

Any high-profile hacking attack has proven that web security still remains a serious issue for any business that’s running its operations online. Web servers are one of the most targeted public faces of an organization, because of the sensitive data they usually host.  Hence, securing web server is as important as securing the website or web application itself.  If we have a secure web application and an insecure web server, or vice versa, it still puts business at a huge risk. Therefore, it is important for us to have a secured web server.


What is a Web Server?? A Web Server can be defined as an HTTP protocol dependant server used for re-direction of the client requests to the appropriate application servers. Following is the pictorial representation of the purpose of a web server:

*Security Implementation in Apache Web Server: Below is the schematic representation of the communication with a secured web server.

The security implementation inside the web server is implemented in two different steps:-

1) Installation of SSL Certificate

2) By following the security guide lines

Installation of certificate:- The installation of the SSL certificates for apache servers involves the following stages:

1. Create a Certificate Signing Request (CSR)
2. Apply online
3. Installing your Certificate
4. Displaying your Secure Site Seal


  1. For a webserver generate a CSR and a private key, use the following command:                                                       openssl req -config openssl.cnf -new -out my-server.csr


2. Removes the pass phrase from the private key because it contains the entropy information for creating the key and could be used for cryptographic attacks against your private key using the command:

rsa -in privkey.pem -out my-server.key

3.  Use the below command to generate the self signed certificate (later replace this with the certificate from Certifying Authority)

x509 -in my-server.csr -out my-server.cert -req -signkey my-server.key -days 365


4.  Create an Apache/conf/ssl directory and move my-server.key and cert into it


5.  Open the httpd.conf file and add the following lines:

LoadModule ssl_module modules/


6.   Add the following to the end of httpd.conf:

<code>        SSLMutex sem</code>
<code>        SSLRandomSeed startup builtin</code>
<code>        SSLSessionCache none</code>
<code> </code>
<code>        SSLLog logs/SSL.log</code>
<code>        SSLLogLevel info</code>
<code>        &lt;VirtualHost&gt;</code>
<code>        SSLEngine On</code>
<code>        SSLCertificateFile conf/ssl/my-server.cert</code>
<code>        SSLCertificateKeyFile conf/ssl/my-server.key</code>



Restart the Apache server and access the applications with the SSL mode.


Following are some of the tips and guidelines implementing, will help our apache servers to be more and more secured:-

1)      Update the Apache Server with the latest security patched and fix pack. (stable version of Apache)

2)      Hide the Apache Version number, and other sensitive information as below inside httpd.conf:

                       ServerSignature Off
                       ServerTokens Prod
<strong><span style="text-decoration: underline">Note</span></strong>: ServerSignature Off tells apache not to display the server version on error pages, or other pages it generates.
ServerTokens Prod tells apache to only return Apache in the Server header, returned on every page request.

3)      Many at times the apache installation run as anonyms or root, make sure that the apache is running under its own user account and group. You can check this information in httpd.conf:

        User apache
        Group apache


4)      Make sure that apache doesn’t use/access any of the files outside its web root directory (this is the location where we have all of apache files):


               <Directory />
                 Order Deny,Allow
                 Deny from all
                 Options None
                 AllowOverride None
               <Directory /web>
                 Order Allow,Deny
                 Allow from all


5)      In typical operation, Apache is started by the root user. Set the right permissions on ServerRoot Directories as follows:


mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs


6) **Server Side Includes (SSI) presents an administrator with several potential security risks like increased load on the server, etc. Hence, turn off server side includes by Options directive inside a Directory tag inside the httpd.conf file. Set Options to either None or –Includes.


7)      Allowing users to execute ***CGI scripts in any directory should only be considered if:

Ø      You trust your users not to write scripts which will deliberately or          accidentally expose your system to an attack.

Ø      You consider security at your site to be so feeble in other areas, as to make one more potential hole irrelevant.

Ø      You have no users, and nobody ever visits your server


8)      Watch logs to keep up-to-date about what is actually going on against your server you have to check the Log Files. They will give you some understanding of what attacks is thrown against the server and allow you to check if the necessary level of security is present.

chown -R root:root /usr/local/apache
               chmod -R o-rwx /usr/local/apache
<em><span style="text-decoration: underline">Note</span></em>: /usr/local/apache is Apache installation directory

9)      Lower the time out and restrict request body requests as follows:

               Timeout 45
               LimitRequestBody 1048576

10)   Restrict the accessing of resource by using the IP restriction:

               Order Deny,Allow
               Deny from all
               Allow from


Note: **Server Side Include page is typically an HTML page with embedded command(s) that are executed by the Web server.


***CGI program is any program designed to accept and return data that confirms to the CGI specification. The program could be written in any programming language, including C, Perl, Java, or Visual Basic. CGI programs are the most common way for Web servers to interact dynamically with users






All Server States using WLST

This is an extension to my earlier post which gives the runtime attributes about the alive servers.

However there could be scenarios where you might want to keep a track of all the server states like RUNNING, SHUTDOWN  etc  in the domain.

The below WLST script provides a list of all the servers in the domains and their respective server states. To check the servers which are in shutdown state.


1. Script to monitor all the Server States in the domain.

a. Save the below script on to your local machine.


username = 'weblogic'

password = 'weblogic1'







for server in serverList:




if serverState=='SHUTDOWN':

print '**** Shutdown Servers ****'

print 'Server *****'+ name +'***** State *****'+serverState


print 'Server *****'+ name +'***** State *****'+serverState




2. Execute the WLST Script

a.  Set the CLASSPATH by running the setDomainEnv script from the

Alternatively you can set the CLASSPATH by specifying the –cp argument while executing the WLST Script

For Ex:  java –cp $BEA_HOME/wlserver_10.3/server/lib/weblogic.jar  weblogic.WLST



You can download the WLST script from the below link.

Note: Save the script as



Wonders Team.

Certificate Management in WebSphere Application Server

Before, trying to understand about the certificate management, installation of certificates inside the WebSphere application server we should first understand why we need ssl communication and what is the impact of not installing the certificates.

During the olden days whenever we want to make any banking transaction (e.g.: depositing the money, with draw money, transfer money, etc), make a reservation for Air travel, etc… we used to visit the branches, stand in the queue and wait for our turn and complete the transaction. But, in present day with time constraint, busy world none of us wants to waste time being in queue. Thanks to the internet based applications which made every work possible with a finger click. But, always a question remains how about the security to these transactions on the internet??.

The JSSE (JAVA Secured Socket Extension) is a set of packages that enable secure Internet communications. It implements a Java technology version of Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. It includes functionality for data encryption, server authentication, message integrity & optional client authentication.


SSL configuration:  SSL configuration help us in making secured communication between the application deployed inside the websphere and external client (browser) by encapsulating the data as required by JSSE. These certificates inside the websphere are mainly of 2 different types. They are as follows:-

(a)     Self Signed certificates ( or Internal or Default Certificates)

(b)     Signer Certificates (or Digital Certificates)


Self Signed Certificates: From websphere application server 6.1 onwards the self signed certificates are created automatically during the profile creation .i.e., whenever the profile is federated to cell self signed certificated are created automatically. The management of these self signed certificates is automatically taken care. The expiration of these certificates is monitored on a pre-defined schedule with notifications sent to system logs and email-sending capabilities. The certificates will be automatically replaced before expiration, by default, and, there will of course be a warning prior to the certificate replacement.


Signer Certificates: A signer certificate represents certificate and public key associated with some personal certificate. The signer certificate explicitly trusts connections made to or by the owner of the associated personal certificate. The signer certificate is typically made completely public by the owner of the personal certificate, but it’s up to the receiving entity to determine if it is a trusted signer prior to adding it to the trust store.

Following are the steps involved for installing the SSL signer certificates:-

1)      **Invoke the ikeyman from the profiles bin directory.

2)      In the IBM Key Management Utility, click on Key Database File and then New

3)    Choose Key database type and select JKS. Give any name to keystore like Test_key.jks.

4)      Click the Browse button and give location where we want to store keystore file.

5)      Click OK. Enter a password and click OK.

6)      Click Create then New Certificate Request to bring up the Create New Key and Certificate Request window.

7)      Type a Key Label, Common Name, Organization, Locality, State, and select a Country. Select 1024 for Key Size.


8)      Click on Key Database File and then Open. Locate the keystore file that you created when you generated the CSR. Type the password and click OK.

9)      Select Signer Certificates from the pull-down list.

10)   Click the button to Add…

11)   Login to WAS console with the valid credentials and Expand “Security” link at left hand side pane.

12)  Click on “SSL certificate and key management”.

13)  Click on “SSL configurations” link.

14)   Click on “Key stores and certificates” link.

15)  Select the scope by clicking on CellDefaultTrustStore (or NodeDefaultTrustStore) link from the list.

16)   Click on “Signer certificates” link.

17)   Click on Add button.

18)   Give alias name as “Test_Cert”.

19)  Give filename as complete path of “Test_Cert.cer” on server.

20)  Click apply and then OK and restart all the WAS server instances.



Weblogic-wonders Team

Installation of WAS Fix pack

Steps to install the Fixpack:-
Following is the step-by-step approach for installing the fixpacks for WebSphere Application Server environment:-

(1) Take the back-up of the existing configuration. You run the below command to take the backup of the existing
configuration from the individual profiles-
(a) ./ (unix)
(b) backupConfig.bat  (windows)

(2) Download the update installer (for WAS6.1 use

Note: While downloading the update installer make sure that the version of update installer is more than your websphere application server installation. Check the WAS version  by running the below commands from appserver profiles bin folder) :

(a) ./ (unix)

(b) versionInfo.bat (windows)

(3) Now, we can start the installation of fix pack to the existing WAS installation by using the following two different ways-
(a) Silent Mode — Generally, this mode is used for windows or UNIX based OS
(b) Graphical Mode — This mode is generally used for windows based OS

Graphical User Interface: Following are the steps for installation of fix packs using the GUI mode:-

(1) Download the required fix pack from the official IBM support Web site ( in to temporary directory updi_root /maintenance directory.

(2) Make the current working directory: updi_root.

(3) Ensure that you stop all running processes. (we can use ps -ef|grep java and kill -9)

(4) Launch the Update Installer. For example:
(a) Windows – update.bat
(b) Windows Vista – update.exe
(c) AIX,HP-UX,Linux,Solaris – ./

(5) The Welcome panel will display. Click Next.

(6) The system will prompt for the location of the product that you want updated. Click Next.

(7) The system will present the choices of Install or Uninstall maintenance. The install option is the default. Click Next.

(8) The system will prompt for the maintenance location where packages can be found. Enter the directory name containing the packages, or browse for the required directory. Click Next.

(9) The following options exist for installing a fix pack:
(a) For installing the fix pack without the feature pack, select the desired fix pack. Click Next.
(b) For installing the fix pack with the feature pack, select the desired fix pack. Another panel is displayed that prompts you to install the enabling interim fix. Click Next.

(10) Before the installation, the Confirmation panel will confirm which packages will be installed.

(11) After the installation, the Summary panel will list which packages have been installed.

(12) After you install the fix pack, check the installation log to verify that the install was successful. The log can be found at app_server_root /logs/update/maintenance_package.install.

Note: (1) By any one of the following messages in the log file we can confirm the status of fix pack installation.
(a) INSTCONFSUCCESS – The operation was a success.
(b) INSTCONFPARTIALSUCCESS – The operation was partially successful, refer to the log for more details.
(c) INSTCONFFAILED – The operation failed, refer to the log for more details

(2)*** The update installer and WAS installation should be installed by using the same user id belonging to the group id.


weblogic-wonders team

BASIC Authentication in Websphere Application Server

1 ) Secure the application resources using the descriptor (web.xml)

<!DOCTYPE web-app PUBLIC “-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN” “”>
<web-app id=”WebApp”>











2) Deploy the application on Websphere Application Server.

3)  Go to

Enterprise Applications > Test_Basic_war > Security role to user/group mapping

You will see the application role configured in the web.xml. Map the users to this role from WAS Console.

Step 4) Go to

Security> Secure administration, applications, and infrastructure  and Check Enable application security.

Restart your Server.

Step 5) Access your application, you will be prompted for authentication.


Let us know if you face any issues.



Wonders Team