Wednesday, March 16, 2011

This is a new series on the blog which gives you tips and important commands you can use at your work to simplify your administration and BAU tasks. All these commands provided in this series of posts will work on Linux/Unix machines.
In the first post, we have 2 tips for you.
1. Finding a Zombie process:
Sometimes when you issue TOP command you see some process under Zombie state apart from the running/sleeping/waiting process. What is a Zombie process? a zombie process or defunct process is a process that has completed execution but still has an entry in the process table. This entry is still needed to allow the process that started the (now zombie) process to read its exit status.
ps -el | grep ‘Z’
Process states and explanation
  • S : sleeping
  • R : running
  • D : waiting (over het algemeen voor IO)
  • T : gestopt (suspended) of getrasseerd
  • Z : zombie (defunct)

2. Sorting the files in a directory by their size
The following command list the size of all sub folders and files from the current location, with sorting
du -a –max-depth=1 | sort –n | more
If you want bigger sized files to appear first, then
du -a –max-depth=1 | sort –nr | more

The setup is as follows:
The request flows in the following order: Web Browser –> IBM Http Server –> WebSphere Plug-in –> WebSphere Application Server.
This involves setting SSL for two different communications.
  • 1. Between Browser and IBM http server [IHS]
  • 2. Between IBM http server [IHS] and Websphere Application Server
In this part, let us take the, SSL setup for IHS. [between browser and IHS]. This involves, editing httpd.conf file and creating a new SSL certificate.
Creating new SSL digital Certificate using iKeyman:
For the certificate you can use either a certificate that is signed by a certificate authority or you can also use a self-signed certificate.  Before creating a new certificate, you need to create a certificate store or Key Database.
  • start the iKeyman utility: /IHS root/bin/ikeyman.sh
  • From the Menu Bar select Key Database File > New.
  • Choose the key database type as CMS
  • Enter a file name for the new Key Database file you are creating
  • Enter a Location for the location where you want to store the .kdb file
  • Click OK
  • After saving the key database file to the location specified, you are prompted to enter a password. This is the password that will be used to open the key database file in iKeyman in the future.
  • make sure checkbox Stash the password to a file is enabled. this saves the encrypted password file as a .sth file in the same directory as the key database file.
  • Now Click OK
Your Key Database file is Ready.
Now lets create a certificate request. Iam using this URL for my site http://www.josephamrithraj.mp/
  • First, Open the KDB using ikeyman. This will show the key database contents.
  • Click on the "down arrow" to the right, to display a list of three choices.
Select Personal Certificate Requests and click New.
Now, a new window will pop up. here you need to input details about the certificate and your organization.
 
Options:
  • Key Size= 1024 for 128bit and 512 for 56bit
  • Common Name= SiteName, [This is the name that the CA will register]
  • Organization= Company Name
  • Enter the name of a file in which to store the certificate request = This is the file (.arm) that will contain your request
Once you save the file (.arm) you are done with creating the request
You must now choose a CA and send them a the "Certificate Request"
Once the CA has signed your certificate, generally they send you back the signed certificate through email.
  • Take the information provided in the CAs email and copy it to a text file (notepad) and save it as IHS_Root/SSL/CertRcvd.arm
  • Open the KDB file and choose Personal Certificates from the drop down options [ check image3 for how-to]
  • From the Personal Certificates section, click Receive, a pop-up window will come
Input the required data. Like  certificate name and location and click OK
Preparing IHS for SSL:
Open the httpd.conf file for editing and modify it to implement the follwoing:
  • For the host_name.domain, use the virtual host IP address or fully qualified domain name.
  • Typically, port 443 is used for HTTPS protocol.
  • The timeout values are given in seconds. Your values might be different.
Sample httpd.conf file for a UNIX computer:
    LoadModule ibm_ssl_module libexec/mod_ibm_ssl.so
    AddModule mod_ibm_ssl.c
    Listen 443

    <VirtualHost host_name.domain:443>
    ServerName host_name.domain
    SSLServerCert certificate name
    DocumentRoot "IHS_Root\docs"
    SSLEnable
    SSLClientAuth none
    <\VirtualHost>

    SSLDisable
    Keyfile "path_to_keyfile_created"
    SSLV2Timeout 100
    SSLV3Timeout 1000

Restart IBM HTTP Server for the changes take effect.
Example SSL virtualhost stanza:
<VirtualHost xxx.xxx.xx.xx:443>
ServerName www.josephamrithraj.mp
SSLEnable
SSLClientAuth None
SSLServerCert mywebsite
<Directory "/home/joseph/website">
Options Indexes
AllowOverride None
order allow,deny
allow from all
</Directory>
DocumentRoot "/home/joseph/website"
</VirtualHost>

in the next part. let us see how to secure the communication between IHS and Websphere
IBM Http Server – Client Authentication and Ciphers
In the previous post, we discussed how to setup SSL between browser and IBM http server [IHS]. In this article, lets discuss how can we set up advanced security for the setup we already did.
The Advanced SSL Configuration settings are
  • Client Authentication
  • Setting Ciphers
  • SSL for multiple IP virtual Hosts
Client Authentication:
If you enable client authentication, the server validates clients by checking for trusted certificate authority, Known as CA root certificates in the local key database. To enable client authentication, you need to use SSLClientAuth directive. The options to use with this stanza are:
  • None – The server requests no client certificate from the client.
  • Optional – The server requests, but does not require, a client certificate. If presented, the client certificate must prove valid.
  • Required – The server requires a valid certificate from all clients and returns a 403 status code if no certificate is present.
  • Required_reset – The server requires a valid certificate from all clients, and if no certificate is available, the server sends an SSL alert to the client. This enables the client to understand that the SSL failure is client-certificate related, and will cause browsers to re-prompt for client certificate information on subsequent access. make sure you have GSKit version 7.0.4.19 or later when you choose this option.
For example, If i want all the clients to be authenticated, then i need to add the following stanza
SSLClientAuth required
Ciphers
We set the cipher specification to use during secure transactions. The specified cipher specifications validate against the level of the Global Security Kit (GSK) toolkit that is installed on your system. Invalid cipher specifications cause an error to log in the error log. If the client issuing the request does not support the ciphers specified, the request fails and the connection closes to the client. IBM HTTP Server has a built-in list of cipher specifications to use for communicating with clients over Secure Sockets Layer (SSL).  The actual cipher specification that is used for a particular client connection is selected from those which are supported by both IBM HTTP Server and the client.
Some cipher specifications provide a weaker level of security than others, and might need to be avoided for security reasons. Some of the stronger cipher specifications are more computationally intensive than weaker cipher specifications and might be avoided if required for performance reasons. When an SSL connection is established, the client (web browser) and the web server negotiate the cipher to use for the connection. The web server has an ordered list of ciphers, and the first cipher in that list which is supported by the client will be selected.
IBM HTTP Server supports the following SSL ciphers: SSLv3 and TLS and SSLv2
IBM recommends the following setting, keeping in mind both strong security and performance
  ## SSLv3 128 bit Ciphers
  SSLCipherSpec SSL_RSA_WITH_RC4_128_MD5
  SSLCipherSpec SSL_RSA_WITH_RC4_128_SHA
  ## FIPS approved SSLV3 and TLSv1 128 bit AES Cipher
  SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA
  ## FIPS approved SSLV3 and TLSv1 256 bit AES Cipher
  SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA
  ## Triple DES 168 bit Ciphers
  ## These can still be used, but only if the client does
  ## not support any of the ciphers listed above.
  SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA
  ## The following block enables SSLv2. Excluding it in the presence of
  ## the SSLv3 configuration above disables SSLv2 support.
  ## Uncomment to enable SSLv2 (with 128 bit Ciphers)
  #SSLCipherSpec SSL_RC4_128_WITH_MD5
  #SSLCipherSpec SSL_RC4_128_WITH_SHA
  #SSLCipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5
View the Ciphers which the server uses for Secure transactions
Set the LogLevel to info in the configuration file. Look in the error log for messages in this format: TimeStamp info_message mod_ibm_ssl: Using Version 2/3 Cipher: longname|shortname. The order that the cipher specifications are displayed in the error log from top to bottom represents the attempted order of the cipher specifications.
View the Ciphers were used for negotiating a connection
You can use the following LogFormat directive to view and log the SSL cipher negotiated for each connection:
LogFormat “%h %l %u %t \”%r\” %>s %b \”SSL=%{HTTPS}e\” \”%{HTTPS_CIPHER}e\” \”%{HTTPS_KEYSIZE}e\” \”%{HTTPS_SECRETKEYSIZE}e\”" ssl_common
CustomLog logs/ssl_cipher.log ssl_common
This logformat will produce an output to the ssl_cipher.log that looks something like this:
127.0.0.1 – - [01/Sep/2010:00:02:05 -0800] “GET / HTTP/1.1″ 200 1582 “SSL=ON” “SSL_RSA_WITH_RC4_128_MD5″ “128″ “128″
SSL for multiple IP virtual hosts
When you do not define an SSL directive on a virtual host, the server uses the directive default. You can define different (SSL) options for various virtual hosts. To enable SSL:
  • Specify the SSLEnable directive on the virtual host stanza in the configuration file, to enable SSL for a virtual host.
  • Specify a Keyfile directive and
  • Any SSL directives you want enabled for that particular virtual host.
  • Restart the server.
With all the above security options enabled, your virtual host may look like this:
<VirtualHost *:443>
SSLEnable
Keyfile keyfile.kdb
SSLCientAuth required
## SSLv3 128 bit Ciphers
SSLCipherSpec SSL_RSA_WITH_RC4_128_MD5
SSLCipherSpec SSL_RSA_WITH_RC4_128_SHA
## FIPS approved SSLV3 and TLSv1 128 bit AES Cipher
SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA
## FIPS approved SSLV3 and TLSv1 256 bit AES Cipher
SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA
## Triple DES 168 bit Ciphers
## These can still be used, but only if the client does not support any of the ciphers listed above.
SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA
## The following block enables SSLv2.
## Excluding it in the presence of  the SSLv3 configuration above disables SSLv2 support.

## Uncomment to enable SSLv2 (with 128 bit Ciphers)
#SSLCipherSpec SSL_RC4_128_WITH_MD5
#SSLCipherSpec SSL_RC4_128_WITH_SHA
#SSLCipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5
</VirtualHost
Creating a Dedicated Profile for LiveCycle in WebSphere ND
The 64-bit version of WebSphere Application Server 6.1 ND does not come with a “Profile Management Tool” (PMT). IBM expects people to use the manageprofiles (.bat or .sh) script in the /bin folder of the WebSphere installation (C:\WebSphere\AppServer\bin\ for example). It is a good idea to create a dedicated WebSphere profile for LiveCycle instead of default ones named AppSrv01, AppSrv02 etc.
Here is a sample command (SUSE Linux Enterprise Server 10 example) to create a WebSphere profile called “LiveCycle”:./manageprofiles.sh -create -profileName LiveCycle -profilePath /opt/WebSphere/AppServer/profiles/LiveCycle -templatePath /opt/WebSphere/AppServer/profileTemplates/managed
If the command succeeds, the response would be something like this:
INSTCONFSUCCESS: Success: Profile LiveCycle now exists. Please consult /opt/WebSphere/AppServer/profiles/LiveCycle/logs/AboutThisProfile.txt for more information about this profile.
If you navigate to /opt/WebSphere/AppServer/profiles/, you will see that there now is a folder called LiveCycle there containing the new profile.
Change folder to the /bin folder of the new LiveCycle profile and federate the node to your cell. Make sure that the Deployment Manager process that manages the WebSphere cell is running. Run a command that looks like this (SUSE Linux Enterprise Server 10 example):./addNode.sh DMgr.company.com DMgr_SOAP_ADDRESS
where DMgr.company.com is the DNS name of the server running the Deployment Manager process that manages the WebSphere cell.
If successful, you will get a response such as this:
Node ServerDNSNameNode01 has been successfully federated.
Here ServerDNSName is the DNS name of the node you just federated without its DNS suffix. This will also start the Node Agent for the node.
This new node (ServerDNSNameNode01 ) will now be visible in the WebSphere Admin Console. You are now ready to create the server and/or clusters to deploy LiveCycle. Please note that the LiveCycle Configuration Manager (LCM) only configures servers and/or clusters. It does not create them for you.
Here is a sample command (SUSE Linux Enterprise Server 10 example) to delete an existing WebSphere profile called “LiveCycle”:./manageprofiles.sh -delete -profileName LiveCycle
If successful, you will get a response such as this:
INSTCONFSUCCESS: Success: The profile no longer exists