Monday, April 4, 2016

Webmin: Browser Based Managemen of Your Server

What is Webmin?

Webmin is a web-based interface for system administration for Unix. Using any modern web browser, you can setup user accounts, Apache, DNS, file sharing and much more. Webmin removes the need to manually edit Unix configuration files like /etc/passwd, and lets you manage a system from the console or remotely. See the standard modules page for a list of all the functions built into Webmin.

Official website:  http://www.webmin.com

Introduction To Webmin

Webmin is a web-based interface for system administration for Unix. Using any browser that supports tables and forms (and Java for the File Manager module), you can setup user accounts, Apache, DNS, file sharing and so on.
Webmin consists of a simple web server, and a number of CGI programs which directly update system files like /etc/inetd.conf and /etc/passwd. The web server and all CGI programs are written in Perl version 5, and use no non-standard Perl modules.

Who developed Webmin?

Almost all the development of Webmin was done by Jamie Cameron, though many people have contributed patches and translations into additional languages. There are also many third-party modules that were developed by other people separately.

Cloudmin 8.4 released

This release adds per-owner bridge limits, LXC 1.1 support, numerous fixes for newer OpenVZ and KVM versions, better handling of locked and shut-down VMs, timeouts for all remote commands (to prevent hung Cloudmin operations), and a whole bunch of other minor bugfixes.
Current users will be able to install it from our YUM and APT repositories. An installer for the Xen and KVM GPL version is available on the Cloudmin GPL for Xen and Cloudmin GPL for KVM pages.

Virtualmin 5.0 released

This major update includes Let's Encrypt support, a huge number of script installer releases, better association between logged backups and schedules, support for PHP 7 (and additional PHP installs), an API command to rename domains, the ability to exlude selected databases from backups, support for off-site spam filtering MX servers, and much more.
You can get the GPL version from the Virtualmin downloads page, or from our YUM and APT repositories.

Webmin 1.780 released

This update includes updates to the Filemin file manager and Authentic theme, and the German, Catalan, Polish and Norwegian translations. It also supports SSL certificate requests from Let's Encrypt, MySQL 5.7, automatic DNS records in partial reverse domains, and includes a bunch of other bugfixes and small features. You can get it from the Webmin downloads page, or from our YUM or APT repositories.



Webmin Browser Based Management on a Raspberry Pi 2



How to Install and Setup Chef Workstation on Linux

Chef is an IT infrastructure automation software, which can be used to manage all your servers and network equipments in your organization.
You need a chef workstation when you want to interact with the chef server, or any physical nodes (servers, network equipments, etc) in your infrastructure.
On a chef workstation, using several chef related commands (for example, knife), you can create cookbooks, or create recipes that will be executed on the individual nodes. You can also bootstarp a new node from chef workstation.
This tutorial explains how you can install and configure Chef workstation on a Linux server.

Chef Logo

Download ChefDK

ChefDK stands for Chef Development Kit. ChefDK is available for almost all platforms including Debian Based Distros, Ubuntu, RedHat Based Distros like CentOS, Mac OS X, and Windows.
The current stable version of ChefDK is 0.11.2, For RHEL based system, it is available for both version 6 and version 7 (i.e CentOS 6 and CentOS 7). The packaged RPM version is only available for 64-bit version.
Download, it from here, or use the direct URL as shown below.

For CentOS 7, use the following:
cd ~
wget https://packages.chef.io/stable/el/7/chefdk-0.11.2-1.el7.x86_64.rpm
For CentOS 6, use the following:
cd ~
wget https://packages.chef.io/stable/el/6/chefdk-0.11.2-1.el6.x86_64.rpm

Install ChefDK

Install the ChefDK using the RPM that we downloaded above.
# rpm -ivh chefdk-0.11.2-1.el7.x86_64.rpm 
Preparing...                          ################################# [100%]
Updating / installing...
   1:chefdk-0.11.2-1.el7              ################################# [100%]
Thank you for installing Chef Development Kit!
This will install ChefDK under /opt/chefdk as shown below.
# ls -l /opt/chefdk/
drwxr-xr-x. 2 root root  4096 Mar  3 13:50 bin
drwxr-xr-x. 7 root root    62 Mar  3 13:50 embedded
-rw-r--r--. 1 root root 13249 Feb 22 14:26 version-manifest.json
-rw-r--r--. 1 root root  8233 Feb 22 14:26 version-manifest.txt

Verify ChefDK Installation

Execute chef verify, which will verify all different components that comes with ChefDK to make sure they all works properly without any issues as shown below.
# chef verify
Running verification for component 'berkshelf'
Running verification for component 'test-kitchen'
Running verification for component 'tk-policyfile-provisioner'
Running verification for component 'chef-client'
Running verification for component 'chef-dk'
Running verification for component 'chef-provisioning'
Running verification for component 'chefspec'
Running verification for component 'generated-cookbooks-pass-chefspec'
Running verification for component 'rubocop'
Running verification for component 'fauxhai'
Running verification for component 'knife-spork'
Running verification for component 'kitchen-vagrant'
Running verification for component 'package installation'
Running verification for component 'openssl'
Running verification for component 'inspec'
.......
---------------------------------------------
Verification of component 'test-kitchen' succeeded.
Verification of component 'chef-dk' succeeded.
Verification of component 'chefspec' succeeded.
Verification of component 'rubocop' succeeded.
Verification of component 'knife-spork' succeeded.
Verification of component 'openssl' succeeded.
Verification of component 'berkshelf' succeeded.
Verification of component 'chef-client' succeeded.
Verification of component 'fauxhai' succeeded.
Verification of component 'inspec' succeeded.
Verification of component 'tk-policyfile-provisioner' succeeded.
Verification of component 'kitchen-vagrant' succeeded.
Verification of component 'chef-provisioning' succeeded.
Verification of component 'package installation' succeeded.
Verification of component 'generated-cookbooks-pass-chefspec' succeeded.
The following is an example case, where the chef verify failed. Also, please note that ruby is required by Chef, which comes embedded within ChefDK.
# chef verify
..
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/mixlib-shellout-2.2.6/lib/mixlib/shellout.rb:289:in `invalid!': Expected process to exit with [0], but received '1' (Mixlib::ShellOut::ShellCommandFailed)
---- Begin output of /usr/bin/ohai -v ----
STDOUT: 
STDERR: /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/dependency.rb:319:in `to_specs': Could not find 'chef-config' (= 12.8.0) - did find: [chef-config-12.7.2] (Gem::LoadError)
We are getting this error message: “Could not find ‘chef-config’ (= 12.8.0) – did find: [chef-config-12.7.2] (Gem::LoadError)”
In the above error message, the chef-config that came with the ChefDK was 12.7.2, which is an older version, which was not compatible in this setup. So, in this case, I installed the chef-config version 12.8.0 manually.
After that, when I ran the chef verify, it didn’t give the above error message.

Verify the ChefDK version

When you execute the chef –version command, it will show the version number of ChefDK and all the components that comes with it as shown below.
# chef --version
Chef Development Kit Version: 0.11.2
chef-client version: 12.7.2
berks version: 4.2.0
kitchen version: 1.5.0

Setup Chef ENV variables

You should also setup Chef related environment variables. For example: GEM_ROOT, GEM_HOME, GEM_PATH.
export GEM_ROOT="/opt/chefdk/embedded/lib/ruby/gems/2.1.0"
export GEM_HOME="/root/.chefdk/gem/ruby/2.1.0"
export GEM_PATH="/root/.chefdk/gem/ruby/2.1.0:/opt/chefdk/embedded/lib/ruby/gems/2.1.0"
Also, if you have ruby already installed on your system, you should update your PATH variable accordingly to use the ruby that comes with the chefDK as shown below.
export PATH="/opt/chefdk/bin:/root/.chefdk/gem/ruby/2.1.0/bin:/opt/chefdk/embedded/bin:/opt/chefdk/bin:/root/.chefdk/gem/ruby/2.1.0/bin:/opt/chefdk/embedded/bin:/opt/chefdk/bin:/root/.chefdk/gem/ruby/2.1.0/bin:/opt/chefdk/embedded/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin"
The following command will show you all Chef environment variables that should be set.
chef shell-init bash
The quick way to set these environment variable is to add the above line to your .bash_profile file as shown below.
echo 'eval "$(chef shell-init bash)"' >> ~/.bash_profile

Firewalld Rules to Access Chef Manage

Next, you need to download the Chef starter kit from your Chef Server that is already running.
To access your Chef Manage GUI, on the Chef Server, add the following firewalld rules to open-up the appropriate ports on the Chef server.
firewall-cmd --direct  --add-rule ipv4 \
filter INPUT_direct 0 -i eth0 -p tcp \
 --dport 443 -j ACCEPT

firewall-cmd --direct  --add-rule ipv4 \
filter INPUT_direct 0 -i eth0 -p tcp \
 --dport 80 -j ACCEPT

firewall-cmd --direct  --add-rule ipv4 \
filter INPUT_direct 0 -i eth0 -p tcp \
 --dport 9683 -j ACCEPT

firewall-cmd --reload

Download Starter Kit from Chef Manage GUI

Login to Chef Manage GUI, and click on “Administration” tab on the top. Next, select the organization from the list. In this example, the organization name is “example”. Once the organization is selected, click on “Starter Kit” from the menu on the left-side as shown below.
Chef Manage Starter Kit
When you click on “Download”, you will get this warning message: Are you certain?: Your user and organization keys will be reset. Are you sure you want to do this?.
Click on Proceed. This will download chef-starter.zip file to your local machine.

Unzip Starter Kit

Transfer the chef-starter.zip file to the Chef workstation, and unzip it under root’s home directory as shown below.
# cd ~
# unzip chef-starter.zip 
Archive:  chef-starter.zip
   creating: chef-repo/cookbooks/
   creating: chef-repo/cookbooks/starter/
   creating: chef-repo/cookbooks/starter/templates/
   creating: chef-repo/cookbooks/starter/templates/default/
  inflating: chef-repo/cookbooks/starter/templates/default/sample.erb  
   creating: chef-repo/cookbooks/starter/files/
   creating: chef-repo/cookbooks/starter/files/default/
  inflating: chef-repo/cookbooks/starter/files/default/sample.txt  
   creating: chef-repo/cookbooks/starter/recipes/
  inflating: chef-repo/cookbooks/starter/recipes/default.rb  
   creating: chef-repo/cookbooks/starter/attributes/
  inflating: chef-repo/cookbooks/starter/attributes/default.rb  
  inflating: chef-repo/cookbooks/starter/metadata.rb  
  inflating: chef-repo/cookbooks/chefignore  
  inflating: chef-repo/README.md     
  inflating: chef-repo/.gitignore    
   creating: chef-repo/.chef/
   creating: chef-repo/roles/
  inflating: chef-repo/.chef/knife.rb  
  inflating: chef-repo/roles/starter.rb  
  inflating: chef-repo/.chef/ramesh.pem  
  inflating: chef-repo/.chef/example-validator.pem
If you are manually setting up the chef-repo folder, then you need to create the above sub-directories manually, and copy the knife.rb file, organization-validator.pem file (for example: example-validator.pem), and username.pem file (for example: ramesh.pem) to the directories shown above.

Get the Chef Server SSL Certificate

At this stage, if you execute knife client list, you’ll get this error message as shown below: “ERROR: SSL Validation failure connecting to host certificate verify failed”
# cd ~/chef-repo
# knife client list
ERROR: SSL Validation failure connecting to host: centos.example.com - SSL_connect returned=1 errno=0 state=error: certificate verify failed
ERROR: Could not establish a secure connection to the server.
Use `knife ssl check` to troubleshoot your SSL configuration.
If your Chef Server uses a self-signed certificate, you can use
`knife ssl fetch` to make knife trust the server's certificates.

Original Exception: OpenSSL::SSL::SSLError: SSL Error connecting to https://centos.example.com/organizations/example/clients - SSL_connect returned=1 errno=0 state=error: certificate verify failed
The certificate verify failed, because we don’t have the SSL certificate downloaded from the Chef server yet.
For this, execute the following “knife ssl fetch” command as shown below.
# cd ~/chef-repo
# knife ssl fetch
WARNING: Certificates from centos.example.com will be fetched and placed in your trusted_cert
directory (/root/chef-repo/.chef/trusted_certs).

Knife has no means to verify these are the correct certificates. You should
verify the authenticity of these certificates after downloading.
This will download the certificate to the following truster_certs directory.
# ls -l /root/chef-repo/.chef/trusted_certs
-rw-r--r--. 1 root root 1379 Mar 20 20:17 centos_example_com.crt

# cat /root/chef-repo/.chef/trusted_certs/centos_example_com.crt 
-----BEGIN CERTIFICATE-----
MIIDzDCCArSgAwIBAgIBADANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEQ
MA4GA1UECgwHWW91Q29ycDETMBEGA1UECwwKT3BlcmF0aW9uczEbMBkGA1UEAwwS
ZXJhdGlvbnMxGzAZBgNVBAMMEmNlbnRvcy5leGFtcGxlLmNvbTCCASIwDQYJKoZI
..
..
WLyr2ORLMcck/OGsubabO/koMNTqhl2JJPECNiDJh06MeZ/2+BOwGZSpXDbw+vFE
NJAsLfsTzihGWZ58einMFA==
-----END CERTIFICATE-----

Final Verification of Chef Workstation

If the chef workstation is working propely, when you execute the “knife client list”, it will display all the clients that are connected to this workstation. Since we just installed it, we’ll see only the validator of your organization as shown below.
# cd ~/chef-repo

# knife client list
example-validator
If you execute this command on an existing chef workstation machine which already has several servers connected to it, you’ll see a list of all the servers that are managed by the chef.
In the following example, we see 5 servers connected to this chef workstation.
# knife client list
example-validator
node1
node2
node3
node4
node5

SSLv2 Vulnerability DROWN Attack: Test and Fix with example

DROWN stands for Decrypting RSA with Obsolete and Weakened eNcryption.
This is from Vulnerability Note VU#583776: Network traffic encrypted using RSA-based SSL certificates over SSLv2 may be decrypted by the DROWN attack.
This is also referred as CVE-2016-0800.
To fix the problem, you should simply disable support for SSLv2 on servers that are using RSA-based SSL certificates. SSLv2 has been deprecated since 2011. There is no reason for you to use SSLv2 anymore.

Two Methods to Test DROWN Vulnerability

There are two ways you can test for DROWN vulnerability:
  1. Go to drownattack test site, and enter the domain name or ip-address of the site that you want to test.
  2. If you want to test the servers that are running behind your firewall, or if you want to automate testing all your servers from command line, use the python script that was developed by Hubert Kario of RedHat as explained below.

Install Python DROWN Test Script

You don’t need to do this on the server that you want to test. You can install the following python script on any of your server (For example, on a dev server), and test all your other servers from this server where this python script is installed.
For this, you should have Python 2.6 or above.
# python --version
Python 2.6.6
You should also have git installed on your system:
# git --version
git version 1.7.1
Create a drown directory.
cd ~
mkdir drown
cd drown
Get the TLSFuzzer using git clone
# git clone https://github.com/tomato42/tlsfuzzer
Initialized empty Git repository in /root/drown/tlsfuzzer/.git/
remote: Counting objects: 480, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 480 (delta 5), reused 0 (delta 0), pack-reused 470
Receiving objects: 100% (480/480), 1.30 MiB | 327 KiB/s, done.
Resolving deltas: 100% (302/302), done.
Checkout the ssl2 branch
# cd tlsfuzzer

# git checkout ssl2
Branch ssl2 set up to track remote branch ssl2 from origin.
Switched to a new branch 'ssl2'
At this stage, you should see the following files under ~/drown/tlsfuzzer directory
# ls
build-requirements.txt  docs  LICENSE  Makefile  README.md  requirements.txt  scripts  setup.py  tests  tlsfuzzer
Next, get tlslite-ng, which is an open source python library that implements SSL and TLS cryptographic protocols.
# git clone https://github.com/tomato42/tlslite-ng .tlslite-ng
Initialized empty Git repository in /root/drown/tlsfuzzer/.tlslite-ng/.git/
remote: Counting objects: 4821, done.
remote: Total 4821 (delta 0), reused 0 (delta 0), pack-reused 4821
Receiving objects: 100% (4821/4821), 1.55 MiB | 137 KiB/s, done.
Resolving deltas: 100% (3570/3570), done.
Next create the appropriate link for the tlslite that we just downloaded above.
# ln -s .tlslite-ng/tlslite tlslite
Checkout the sslv2 branch.
# cd .tlslite-ng/

# git checkout sslv2
Branch sslv2 set up to track remote branch sslv2 from origin.
Switched to a new branch 'sslv2'

# cd ~/drown/tlsfuzzer
Get the ECDSA cryptography python script.
# git clone https://github.com/warner/python-ecdsa .python-ecdsa
Initialized empty Git repository in /root/drown/tlsfuzzer/.python-ecdsa/.git/
remote: Counting objects: 485, done.
remote: Total 485 (delta 0), reused 0 (delta 0), pack-reused 485
Receiving objects: 100% (485/485), 180.60 KiB, done.
Resolving deltas: 100% (289/289), done.
Create appropriate link for the python ECSDA script.
# ln -s .python-ecdsa/ecdsa ecdsa

Test DROWN Vulnerability Using Python Script – Not Vulnerable Example

Finally, execute the DROWN python script as shown below. Change the ip-address appropriate to the server that you are testing. You can also use domain name instead of ip-address here.
# PYTHONPATH=. python scripts/test-sslv2-force-export-cipher.py -h 192.168.101.2 -p 443

Connect with TLSv1.0 EXP-RC4-MD5 ...OK
Connect with SSLv2 EXP-RC4-MD5 ...OK
Connect with SSLv3 EXP-RC4-MD5 ...OK
Connect with TLSv1.0 EXP-RC2-CBC-MD5 ...OK
Connect with SSLv3 EXP-RC2-CBC-MD5 ...OK
Connect with SSLv2 EXP-RC2-CBC-MD5 ...OK

Test end
successful: 6
failed: 0
Note: You should see 6 OK’s above. You should also see “failed: 0”.

Test DROWN Vulnerability Using Python Script – Vulnerable Example

The following is executed on a server that was vulnerable to DROWN attack. This is what you’ll see when it is vulnerable.
# PYTHONPATH=. python scripts/test-sslv2-force-export-cipher.py -h 192.168.101.3 -p 443
Connect with TLSv1.0 EXP-RC4-MD5 ...OK

Connect with SSLv2 EXP-RC4-MD5 ...
Error encountered while processing node <tlsfuzzer.expect.ExpectSSL2Alert object at 0x2259810> (child: <tlsfuzzer.expect.ExpectClose object at 0x2259890>) with last message being: <tlslite.messages.Message object at 0x2259c50>
Error while processing
Traceback (most recent call last):
  File "scripts/test-sslv2-force-export-cipher.py", line 109, in main
    runner.run()
  File "/root/drown/tlsfuzzer/tlsfuzzer/runner.py", line 151, in run
    RecordHeader2)))
AssertionError: Unexpected message from peer: Handshake(58)

Connect with SSLv3 EXP-RC4-MD5 ...OK
Connect with TLSv1.0 EXP-RC2-CBC-MD5 ...OK
Connect with SSLv3 EXP-RC2-CBC-MD5 ...OK
Connect with SSLv2 EXP-RC2-CBC-MD5 ...OK

Test end
successful: 5
failed: 1

Fix the DROWN Attack Issue

In the above DROWN vulnerable scenario, one of the test case failed. To fix this issue, add the following line to the Apache’s httpd.conf, and restart the Apache.
# vi httpd.conf
SSLProtocol All -SSLv2 -SSLv3
If you are running NginX, make sure SSLv2 is not listed in the configuration file as shown below.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
In Apache, we should explicitly say “-SSLv2” to disable SSLv2. But in NginX, when you don’t list SSLv2, it is disabled.
After the above fix, the python DROWN test script didn’t report the issue on that particular server anymore.
Apart from Apache and NginX, if you are running Postfix for your email server, you should disable SSLv2 on your email server also.
Also, upgrade your OpenSSL to the latest version. In the new version, OpenSSL team also have disabled the SSLv2 by default at build-time. OpenSSL team has this suggestion: Upgrade 1.0.2 version to 1.0.2g; and upgrade 1.0.1 version to 1.0.1s.

Additional Reference:

SSLv2 deprecated: Vulnerability Note VU#583776

Overview

Network traffic encrypted using an RSA-based SSL certificate may be decrypted if enough SSLv2 handshake data can be collected. This is known as the "DROWN" attack in the media.

Description

According to the researcher, "DROWN" is a new form of cross-protocol Bleichenbacher padding oracle attack. An attacker using "DROWN" may obtain the session key from a vulnerable server supporting SSLv2 and use it to decrypt any traffic encrypted using the shared certificate.
It allows an attacker to decrypt intercepted TLS connections by making specially crafted connections to an SSLv2 server that uses the same private key."

The SSLv2 protocol is the only protocol directly impacted; however, the researcher's website states that many servers may use a shared certificate between the SSLv2 and the newer TLS protocols. If so, if the certificate is decrypted via SSLv2, then the TLS protocol using the shared certificate can be decrypted as well. The attack requires approximately 1000 SSL handshakes to be intercepted for the attack to be effective.

The researchers have also released a DROWN attack check tool and an FAQ that provides more complete information.

Impact

A remote attacker may be able to decrypt individual messages/sessions of a server supporting SSLv2. Servers using TLS protocol with the same shared certificate as is used for SSLv2 may also be vulnerable. According to the DROWN FAQ, the server private key is not obtained from this attack.

Solution

Disable SSLv2

Network administrators should disable SSLv2 support. The researchers have provided more information on how to disable SSLv2 for various server products.

SSLv2 has been deprecated since 2011.

Do not reuse SSL certificates or key material

This issue can be mitigated on TLS connections by using unique SSL keys and certificates. If possible, do not reuse key material or certificates between SSLv2 and TLS support on multiple servers.

Monitor network and use firewall rules

We recommend enabling firewall rules to block SSLv2 traffic. Since the attack requires approximately 1000 SSL handshakes, network administrators may also monitor logs to look for repeated connection attempts. However, this data may also be obtained via man-in-the-middle or other attacks, not solely from direct connections.

Vendor Information (Learn More)

On Linux, nginx may or may be affected depending on what version of OpenSSL nginx was compiled with. See the vendor list below or contact your vendor to determine if your release of nginx is affected.