Sunday, August 22, 2010

Cloud computing vision

Blog Has Moved

Link to the same post in the new blog: Cloud computing vision

Cloud computing is the latest buzz on the Internet this days.
What does it mean to us and where does the future of Cloud computing goes?

Some background
In the mid 90's, we had Citrix, with its vision for server based-computing.
Works similar to the Mainframe idea who came couple of decades before - you put all your resources on one server, and thin clients connect to receive resources.
Couple of years later, we had new buzz, called ASP (Application service provider), which according to Wikipedia is a business that provides computer-based services to customers over a network.
Few years later, ASP changed its name to SaaS (Software as a service), which also referred to as software on demand.
In between, we had VMware who presented to world (at least the most famous) server virtualization.

What is Cloud Computing?
According to Wikipedia, Cloud computing is Internet-based computing, whereby shared resources, software, and information are provided to computers and other devices on demand, like the electricity grid.
The idea of Cloud computing, enables the customers to avoid investing money on hardware and network equipment, and instead, renting usage from third-party provider.
Cloud computing has the following key features:
* Agility improves with users' ability to rapidly and inexpensively re-provision technological infrastructure resources.
* Cost is claimed to be greatly reduced.
* Device and location independence enable users to access systems using a web browser regardless of their location or what device they are using (e.g., PC, mobile).
* Multi-tenancy enables sharing of resources and costs across a large pool of users.
* Reliability is improved if multiple redundant sites are used, which makes well designed cloud computing suitable for business continuity and disaster recovery.
* Scalability via dynamic ("on-demand") provisioning of resources on a fine-grained, self-service basis near real-time, without users having to engineer for peak loads.
* Maintenance cloud computing applications are easier to maintain, since they don't have to be installed on each user's computer.
* Metering cloud computing resources usage should be measurable and should be metered per client and application on daily, weekly, monthly, and annual basis.

The confusion point and vision
People tend to confuse between companies moving their data-centers and applications toward the cloud, and actual Cloud computing providers.
A real Cloud computing provider is built from large-scale data centers around the world.
Each rack is built from cheap (to manufacture) hot-swappable hardware - it's time to say goodbye to 1U-4U servers from all major vendors (HP, IBM, DELL, SUN, etc).
Each blade has many core CPU (4-core, 6-core and above), with allot of memory (as much as the hardware supports).
Each blade is connected to large-scale storage grid.
Everything must be redundant - you must be able to add new racks on-demand, without affecting any customer.
Servers, network equipment and storage devices must be configured in active-active clusters.
Data should be replicated on the fly between data centers across the world, in-order to provide 24/7 availability.
Guest operating system must be able to move between physical servers, transparently, as VMware introduced in its VMotion technology.
Server maintenance should be performed on schedule basis - since everything is transparent to the customer, firmware upgrades, patch management and software/application upgrades will not affect any customer.
The hardware/network/storage layer should be separated from the application layer, so that current SaaS companies will be able to integrate their current applications to the cloud era, and work transparently with Cloud computing infrastructure.

Cloud computing Achilles
The thing that drives most people off the cloud is security.
Customers can't physically protect their hardware, since they don't own it.
Customers having troubles protecting their data, since everything is built on virtual machines, connected to shared virtual storage.
I hope that in the near future information security professionals will be able to close this gap, and enable customers transparent, cheap and secure solutions.


Friday, August 13, 2010

Generating self-signed SSL certificate using OpenSSL

Blog Has Moved

Link to the same post in the new blog: Generating self-signed SSL certificate using OpenSSL

OpenSSL allows you to request, sign, generate, export and convert digital certificates.
OpenSSL comes by-default in Unix platform as an RPM or package file (RedHat, Solaris, etc).
The guide bellow explains how to generate a key store for digital certificates, generate private and self-signed SSL certificate for web servers, and export/convert the key store to PFX file (for importing to Windows platform).
The guide bellow was tested on common Linux platform web servers (Apache, Lighttpd, Nginx, Resin) however the same syntax should work the same on Windows platform.
Download link for Windows binaries:
Download link for Linux source files (pre-compiled):

1. Install OpenSSL.
2. Run the command bellow to generate a new key store called “server.key
openssl genrsa -des3 -out /tmp/server.key 1024
3. Run the commands bellow to request a new SSL certificate:
openssl req -new -x509 -nodes -sha1 -days 1095 -key /tmp/server.key > /tmp/server.crt

openssl x509 -noout -fingerprint -text < /tmp/server.crt > /tmp/
4. Run the command bellow to backup the key store file that has a password:
cp /tmp/server.key /tmp/server.key.bak
5. Run the command bellow to generate a new key store without a password:
openssl rsa -in /tmp/server.key -out /tmp/no.pwd.server.key
6. Run the command bellow only if you need to generate a PEM file that contains a chain of both the key store and the public key in one file:
cat /tmp/no.pwd.server.key /tmp/server.crt > /tmp/no.pwd.server.pem
7. Run the command bellow only if you need to export a key store (without a password) to a PFX file (for importing to Windows platform)
openssl pkcs12 -export -in /tmp/server.crt -inkey /tmp/no.pwd.server.key -certfile /tmp/no.pwd.server.pem -out /tmp/server.pfx

server.key - Key store file
server.crt - Server SSL public key file
no.pwd.server.key - Key store file (without a password)
no.pwd.server.pem - Key store file + server SSL public key file (without a password)
server.pfx - Private key + public key, exportable for Windows platform (i.e IIS server)

Labels: , , , , , , ,

Tuesday, August 10, 2010

Security Vulnerability Assessment Process and Policy

Blog Has Moved

Link to the same post in the new blog: Security Vulnerability Assessment Process and Policy


In order to maintain high security standards, identify potential vulnerabilities and evaluate the effectiveness of various security controls that were implemented within the infrastructure, it is crucial to perform periodic security assessments.


This procedure defines the controls and steps that are required for identifying security vulnerabilities and ensuring reasonable level of security for the infrastructure and application levels.


External Facing:

1. Perform automated external application level scans on a daily basis for website and application. (e.g. McAfee Secure, Acunetix).
2. Perform automated external network level scans on a weekly basis (e.g. McAfee Secure)
3. Perform in-house, half automated scans with a vulnerability assessment tool (e.g. Qualys)
4. Execute a dedicated application level and network penetration test by a professional third party.
This should be executed twice a year or on every major application release.


1. Discovery: run NMAP scan on all VLANs to identify all the devices and create an asset inventory that outlines devices and services. [weekly / monthly]
2. Network and Infra vulnerabilities: Run a weekly scan with NESSUS or similar tool to identify infrastructure gap and non hardened devices.
3. Purchase and run vulnerability scanner (such as Qualys or NetIQ) – every week.
4. Patch Management:
a. Install Microsoft WSUS server to maintain security patches for Windows infrastructure.
b. Install Linux YUM server to maintain security patches for RedHat infrastructure.
c. Generate reports on weekly basis to find vulnerable systems.
5. Penetration test: run an annual internal pen-test to identify internal gaps with orientation to threats from within the organization.

Implement a Production Change Management policy that includes a hardening and implementation clearance process for new devices (e.g. addition of new network device, operating system, web server, DB server, etc).

Labels: ,

How to implement SSL on Resin 4.0.8

Blog Has Moved

Link to the same post in the new blog: How to implement SSL on Resin 4.0.8

Pre-installation notes
The guide bellow is based on the previous guide Hardening guide for Resin Professional 4.0.8 on RHEL 5.4

1. Login to the server using Root account.
2. Change permissions on the keys folder:
chmod 640 /usr/local/resin/keys
3. Run the command bellow to generate a key pair:
/usr/bin/openssl genrsa -des3 -out /usr/local/resin/keys/server.key 1024
Specify a complex pass phrase for the private key (and document it)
4. Run the command bellow to generate the CSR:
/usr/bin/openssl req -new -newkey rsa:1024 -nodes -keyout /usr/local/resin/keys/server.key -out /tmp/resin.csr
Note: The command above should be written as one line.
5. Send the file /tmp/resin.csr to a Certificate Authority server.
6. As soon as you receive the signed public key from the CA server via email, copy all lines starting with “Begin” and ending with “End” (include those two lines), into notepad, and save the file as "server.crt"
7. Copy the file "server.crt" using SCP into /usr/local/resin/keys/
8. Follow the link on the email from the CA server, to create the Root CA chain, and save it as “ca-bundle.crt” (Note: The file must be PEM (base64) encoded).
9. Copy the file "ca-bundle.crt" using SCP into /usr/local/resin/keys/
10. Edit using VI, the file /usr/local/resin/conf/resin.xml and replace the section bellow from:
<!-- SSL port configuration: -->
<http address="*" port="8443">
<jsse-ssl self-signed-certificate-name="resin@localhost"/>
<http address="Server_DNS_Name" port="443">

Note: Replace “my-password” with the password for the “server.key” file.
11. Restart the Resin services:
/etc/init.d/resin restart
12. Backup the file /usr/local/resin/keys/server.key

Labels: , ,

Monday, August 9, 2010

Hardening guide for Resin Professional 4.0.8 on RHEL 5.4

Blog Has Moved

Link to the same post in the new blog: Hardening guide for Resin Professional 4.0.8 on RHEL 5.4

• JDK 1.6 source file
• Resin Professional 4.0.8 source file

Installation phase
1. Login to the server using Root account.
2. Create a new account:
groupadd resin
useradd -g resin -d /home/resin -s /bin/bash resin
3. Create folder for the web content:
mkdir -p /www
4. Updating Ownership and Permissions on the web content folder:
chown -R root /www
chmod -R 775 /www
5. Copy JDK 1.6 into /tmp
6. Change the permissions on the JDK 1.6:
chmod +x /tmp/jdk-6u20-linux-i586-rpm.bin
7. Run the command bellow to install JDK 1.6:
8. Remove the JDK 1.6 source files:
rm -f /tmp/jdk-6u20-linux-i586-rpm.bin
rm -f /usr/java/jdk1.6.0_20/
rm -rf /usr/java/jdk1.6.0_20/demo
rm -rf /usr/java/jdk1.6.0_20/sample
rm -rf /opt/sun/javadb/demo
rm -rf /opt/sun/javadb/docs
9. Before compiling the Resin environment, install the following RPM from the RHEL DVD:
rpm -ivh kernel-headers-2.6.18-164.el5.i386.rpm
rpm -ivh glibc-headers-2.5-42.i386.rpm
rpm -ivh glibc-devel-2.5-42.i386.rpm
rpm -ivh gmp-4.1.4-10.el5.i386.rpm
rpm -ivh libgomp-4.4.0-6.el5.i386.rpm
rpm -ivh gcc-4.1.2-46.el5.i386.rpm
rpm -ivh pcre-devel-6.6-2.el5_1.7.i386.rpm
rpm -ivh e2fsprogs-devel-1.39-23.el5.i386.rpm
rpm -ivh keyutils-libs-devel-1.2-1.el5.i386.rpm
rpm -ivh libsepol-devel-1.15.2-2.el5.i386.rpm
rpm -ivh libselinux-devel-1.33.4-5.5.el5.i386.rpm
rpm -ivh krb5-devel-1.6.1-36.el5.i386.rpm
rpm -ivh zlib-devel-1.2.3-3.i386.rpm
rpm -ivh openssl-devel-0.9.8e-12.el5.i386.rpm

10. Copy the Resin 4.0.8 source file using PSCP (or SCP) into /tmp
11. Move to /tmp
cd /tmp
12. Extract the resin-pro-4.0.8.tar.gz file:
tar -zxvf resin-pro-4.0.8.tar.gz
13. Move to the Resin 4.0.8 source folder:
cd /tmp/resin-pro-4.0.8
14. Run the commands bellow to compile the Resin 4.0.8 environment:
./configure --with-resin-conf=/usr/local/resin/conf --with-resin-root=/www --with-resin-log=/var/log/resin --enable-ssl --with-java-home=/usr/java/jdk1.6.0_20
Note: The command above should be written as one line.


make install
15. Edit using VI, the file /usr/local/resin/conf/resin.xml and change the string bellow:
<resin:if test="${resin.userName == 'root'}">
<resin:if test="${resin.userName == 'resin'}">



<server id="" address="" port="6800">
<server id="" address="Server_DNS_Name" port="6800">

<http address="*" port="8080"/>
<http address="Server_DNS_Name" port="8080"/>


<host id="" root-directory=".">
<host id="Server_DNS_Name" root-directory="/www">


<resin:set var="resin_admin_external" value="false"/>
<resin:set var="resin_admin_external" value="true"/>
16. Change the ownership on the folder bellow:
chown resin:root -R /www/*
17. Manually start the Resin service:
/usr/local/resin/bin/ start -root-directory /www --log-directory /var/log/resin
18. Manually stop the Resin service:
/usr/local/resin/bin/ stop
19. Copy the Resin license file into /usr/local/resin/licenses
20. Change the ownership and permissions on the folders bellow:
chmod 664 -R /www/watchdog-data/
chmod 777 /www/watchdog-data/default/
chown resin:root -R /www/watchdog-data/*
21. Remove the Resin 4.0.8 source folder:
rm -rf /tmp/resin-pro-4.0.8
22. Remove default documents:
rm -rf /www/doc/resin-doc
23. To start Resin service at server start-up, run the commands bellow:
chkconfig --add resin
chkconfig resin on
/etc/init.d/resin start
24. From a client machine, open an internet browser and login to the address:
25. Enter a username and password in the lower half of the page, then click "Create Configuration File". The recommended username is "admin".
26. Rename the admin-users.xml file:
mv /usr/local/resin/conf/admin-users.xml.generated /usr/local/resin/conf/admin-users.xml
27. Browse back to http://Server_DNS_Name:8080/resin-admin/. The change you made should force Resin to restart and return a 503 error. Just hit refresh in a few moments to bring up the page again.

Labels: ,