Security Vulnerability Alert: POODLE SSLv3.0 vulnerability

Description:
On 14/10, Google researchers had release a vulnerability in SSL 3.0, which could allowed malicious user to decrypt the contents that was supposedly encrypted when visiting SSL enabled websites.  Named POODLE attack ( Padding Oracle on Downgraded Legacy Encryption), a padding attack that targets CBC ciphers in SSL V3.

A detail analysis report of the POODLE exploit by the Google researchers can be found here: https://www.openssl.org/~bodo/ssl-poodle.pdf

Impact
Websites that support SSL V3.0 and CBC cipher mode chaining are vulnerable to the attacks, According to the report, The flaw allows attackers to steal secure HTTP cookies and headers, among other sensitive data.

Mitigation

• Google researchers recommend that support for SSL v3.0 be disable either on the end user browser or server end or both as well as others that rely on downgraded connections ( Warning : Doing this may “break” connectivity to web applications that only able to support up to SSL V3.0  and don’t support TLS 1.0, TLS 1.1, TLS 1.2 )
• If the above is not possible, Google recommends implementing support of “TLS FALLBACK SCSV” the Transport Layer Security Signalling Cipher Suite Value that "prevents protocol downgrade attacks." https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
  
  “This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks," explained Möller.”

More Information

1. http://thenextweb.com/google/2014/10/15/web-encryption-vulnerability-opens-encrypted-data-hackers/
2. http://googleonlinesecurity.blogspot.sg/2014/10/this-poodle-bites-exploiting-ssl-30.html
3. http://blog.erratasec.com/2014/10/some-poodle-notes.html
4. http://www.theregister.co.uk/2014/10/14/google_drops_ssl_30_poodle_vulnerability/
5. Mozilla Blog - https://blog.Mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
6. Microsoft - Disabling SSL 3.0 on Servers - http://support.Microsoft.com/kb/187498
7. Mozilla Add-On - Disabling SSL 3.0 on Mozilla Browser - https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control/

Deploying HAProxy 1.4.24 to load-balance MS Terminal Services on CentOS 6

HAProxy is an open source, free, veryfast and reliable solution offering high availability, load balancing and proxy for TCP and HTTP-based applications. It is particularly suited for very high traffic web sites and powers quite a number of the world's most visited ones. Over the years it has become the de-facto standard opensource load balancer, is now shipped with most mainstream Linux distributions, and is often deployed by default in cloud platforms.

The content of this blog entry is taken from Load balancing Windows Terminal Server – HAProxy and RDP Cookies or Microsoft Connection Broker

 In this blog entry, we will put in a sample working haproxy configuration to load balance between terminal services  

 Step 1: Install haproxy

# yum install haproxy

Step 2: Modify /etc/haproxy/haproxy.cfg  

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
# to have these messages end up in /var/log/haproxy.log you will
# need to:
#
# 1) configure syslog to accept network log events. This is done
# by adding the '-r' option to the SYSLOGD_OPTIONS in
# /etc/sysconfig/syslog
#
# 2) configure local2 events to go to the /var/log/haproxy.log
# file. A line like the following can be added to
# /etc/sysconfig/syslog
#
# local2.* /var/log/haproxy.log
#
log 127.0.0.1 local2

chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4500
user haproxy
group haproxy
daemon
stats socket /var/lib/haproxy/stats

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
timeout queue 1m
timeout connect 60m
timeout client 60m
timeout server 60m

# -------------------------------------------------------------------
# [RDP Site Configuration]
# -------------------------------------------------------------------
listen cattail 155.69.57.11:3389
mode tcp
tcp-request inspect-delay 5s
tcp-request content accept if RDP_COOKIE
persist rdp-cookie
balance leastconn
option tcpka
option tcplog
server win2k8-1 192.168.6.48:3389 weight 1 check inter 2000 rise 2 fall 3
server win2k8-2 192.168.6.47:3389 weight 1 check inter 2000 rise 2 fall 3
option redispatch

listen stats :1936
mode http
stats enable
stats hide-version
stats realm Haproxy\ Statistics
stats uri /

Information:

• timeout client and timeout server is put at 6 hours (360m) to keep idle RDP session established
• persist rdp-cookie and balance rdp-cookie. These instruct HAProxy to inspect the incoming RDP connection for a cookie; if one is found, it is used to persistently direct the connection to the correct real server
• The 2 tcp-request lines help to ensure that HAProxy sees the cookie on the initial request.

  Reference:

• Load balancing Windows Terminal Server – HAProxy and RDP Cookies or Microsoft Connection Broker
• Deploying an HAProxy Load Balancer on CentOS 6

VMWARE had release product updates to address the BASH security vulnerabilities

VMWARE had release product updates to address the BASH security vulnerabilities on 01/10/14 .

It is found at http://www.vmware.com/security/advisories/VMSA-2014-0010.html

Reports have shown using their honeypots system  that Malicious individuals are currently actively scanning for vulnerable and un-patch system and what commands they are attempting  to execute by simply passing URL/command  parameters.

https://www.alienvault.com/open-threat-exchange/blog/attackers-exploiting-shell-shock-cve-2014-6721-in-the-wild
http://blog.sucuri.net/2014/09/bash-shellshocker-attacks-increase-in-the-wild-day-1.html

Unable to open socket connection to xcatd daemon on localhost:3001.

When I did a tabedit site to check my configuration, I encountered this error

Unable to open socket connection to xcatd daemon on localhost:3001.
Verify that the xcatd daemon is running and that your SSL setup is correct.

The solution to this error is quite easy. You just need to check your /etc/hosts. Have you # out your. In other words, make sure you have a line like this in your /etc/hosts

127.0.0.1       localhost.localdomain                   localhost

That's it.....

Compiling VASP 5.3.5 with OpenMPI 1.6.5 and Intel 12.1.5

Just compiled VASP 5.3.5 with OpenMPI 1.6.5 and Intel 12.1.5. Do take a look at Compiling VASP 5.3.5 with OpenMPI 1.6.5 and Intel 12.1.5