How to disable SSLv2 and Weak Cipers and enable SSLv3 on Linux

In order to be Payment Card Industry Data Security Standard PCI-DSS) Compliance v1.2, we are required to use “use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.”

Secure Socket Layer (SSL) version 2 is considered weak cryptography in this aspect. To disabled SSLv2 and enable SSLv3. Assuming you already have OpenSSL installed, you can use another remote server to test the https connections

# openssl s_client -ssl2 -connect remote_server:443

If your server does not support SSLv2, you should receive the following error

CONNECTED(00000003)
22255:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

If your server is enabled to supports SSLv2 connections, the connection will be accepting input

CONNECTED(00000003)

 To use SSLv3 and TLSv1, you have to modify the following at SSLCipherSuite directive in the httpd.conf or /etc/httpd/conf.d/ssl.conf file. In the example, you can do the following

#SSLProtocol all -SSLv2
SSLProtocol -all +SSLv3 +TLSv1

On my /etc/httpd/conf.d/ssl.conf

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

For more information,see

1. How to Disable SSLv2 and Weak Ciphers(PCI Compliance (http://almamunbd.blogspot.com)
2. How to Disable SSLv2 and Weak Ciphers(PCI Compliance (http://www.srcnix.com)

Important Apache (httpd) security Update

An important security update for httpd and solution for

1. 'Devastating' Apache bug leaves servers exposed
2. Apache released 2nd workaround for Devastating' Apache bug

Description of the bugs can be found at CVE-2011-3192

The byterange filter in the Apache HTTP Server 1.3.x, 2.0.x through 2.0.64, and 2.2.x through 2.2.19 allows remote attackers to cause a denial of service (memory and CPU consumption) via a Range header that expresses multiple overlapping ranges, as exploited in the wild in August 2011, a different vulnerability than CVE-2007-0086.

Solution:

# yum update httpd

Upgrading of Broadcom Drivers to resolve eth0 NIC SerDES Link is Down

If the post Encountering eth0 NIC SerDES Link is Down did not resolve your issue and you are still encountering "eth0 NIC SerDES Link" issues, do upgrade the Broadcom Drivers from your vendor site and it will eliminate your issue immediately. Since my vendor is IBM, so I downloaded the Broadcom BNX2 Drivers
Broadcom BNX2 driver version bnx2-2.0.23b for RHEL 5 - IBM System x and BladeCenter

If you are not sure what is your version of drivers, you can do a

# ethtool -i eth0

The version 2.0.8 and above should resolve the above issue

Oh yes, if you are using IBM Products and the above drivers from IBM, after unpacking the drivers from IBM and ensuring you have the necessary prerequistics, just do a

If you are using the Free Clone of Redhat which includes CentOS or Scientific Linux, you may want to temporarily modify the /etc/redhat-release information to simulate a real RHEL Distribution. Vendor patches often requires RHEL distribution

#CentOS release 5.4 (Final)
Red Hat Enterprise Linux AS release 5

# mkdir brcm
# cd brcm
# tar -zxvf brcm_dd_nic_netxtreme2-2.0.23b_1.62.15_rhel5_32-64.tgz
# ./install.pl --update 

 INSTALL_OPTIONS --yes --update


        Drivers will be installed/migrated to 2.6.18-164 version

----------------------------------------------------------------------
Checking kmod-brcm-netxtreme2-6.2.23-1.x86_64.rpm
WARNING: Non Whitelist symbol detected
----------------------------------------------------------------------
kmod-brcm-netxtreme2-6.2.23-1.x86_64.rpm installed successfully
SUCCESS

sys_copy and scp -rpb error captured on pbs_mom logs

I was encountering an interesting scp error on my log file regarding pbs_mom

.......pbs_mom: LOG_ERROR::sys_copy, 
command '/usr/bin/scp -rpB  2014.Head-Node.OU 
userid@headnode:/home/xxx' failed with status=1, 
giving up after 4 attempts

It seems that the error may be due to default MaxStartups 10 setting in the /etc/ssh/sshd_config which is too low a value and scp may be overwhelm

According to manual page
MaxStartups - Specifies the maximum number of concurrent unauthenticated connections to the sshd daemon.  Additional connections will be dropped until authentication succeeds or the LoginGraceTime
expires for a connection. The default is 10.

Try increasing the MaxStartups to 100 at /etc/ssh/sshd_config

MaxStartups 100 

Blade hangs on boot and "FW/BIOS, firmware progress (ABR Status) FW/BIOS ROM corruption

2 of my Blade got hang on boot and suffered this "FW/BIOS, firmware progress (ABR Status) FW/BIOS ROM corruption". For more information on the resolution, do look at Blade hangs on boot and "FW/BIOS, firmware progress (ABR Status) FW/BIOS ROM corruption" message in AMM - IBM BladeCenter HS22, HS22V

From the site,

---

Symptom
When booting BladeCenter HS22 or HS22V with Integrated Management Module (IMM) build yuoo84c installed, the blade may hang at the "UEFI Platform Initializing" screen. The hang will be accompanied by the following event in the chassis Advanced Management Module (AMM) log:
   
FW/BIOS, firmware progress (ABR Status) FW/BIOS ROM corruption

---

Solution
This behavior is corrected in IMM firmware release yuoo91e and newer.
The file is or will be available by selecting the appropriate machine type on the 'Product View' of IBM Support's Fix Central web page, at the following URL:
http://www.ibm.com/support/fixcentral/systemx/groupView?query.productGroup=ibm%2FBladeCenter

---

Workaround
This failure may be reduced by disabling Internet Protocol Version 6 (IPv6) support for the IMM. This can be done via the following steps:
1. Boot the blade to the F1 Unified Extensible Firmware Interface (UEFI) setup screen.
2. Select "System Settings" and press Enter
3. Select "Integrated Management Module" and press Enter
4. Select "Network Configuration" and press Enter
5. Change "IP6" setting to "Disable"
Occasionally, the failure can be recovered by restarting the IMM. If this is not successful, then it is necessary to reseat the blade in the chassis to recover. After a reseat, the blade will boot normally.