Friday, 13 June 2014

LVM2 file systems on Linux

1. Create a partition to hold the LVM2 file system. You can use the whole disk, but this is not recommended. You can use fdisk on disks smaller than 2TB, but will need to use parted on larger disks.
Make sure you use partition type 0x8e for LVM.

2. Create the physical volume:
sudo pvcreate /dev/sdb1
sudo pvscan 

3. Create the volume group:
sudo vgcreate volume_group_name /dev/sdb1
sudo vgdisplay volume_group_name

5. Create a 500 MB volume:
sudo lvcreate -L500 -nvolume_name volume_group_name
sudo lvdisplay volume_group_name

6. Make a file system:
sudo mkfs -t ext4 /dev/mapper/volume_group_name-volume_name

7. Create a mount point:
sudo mkdir /path_to_mount

8. Mount file system:
sudo mount /dev/mapper/volume_group_name-volume_name /path_to_mount

Tuesday, 10 June 2014

Post Heartbleed security advisory

https://www.openssl.org/news/secadv_20140605.txt



6 New Vulnerabilities:



OpenSSL Security Advisory [05 Jun 2014]
========================================

SSL/TLS MITM vulnerability (CVE-2014-0224)
===========================================

An attacker using a carefully crafted handshake can force the use of weak
keying material in OpenSSL SSL/TLS clients and servers. This can be exploited
by a Man-in-the-middle (MITM) attack where the attacker can decrypt and 
modify traffic from the attacked client and server.

The attack can only be performed between a vulnerable client *and*
server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers
are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users
of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.

OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m.
OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h.

Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and
researching this issue.  This issue was reported to OpenSSL on 1st May
2014 via JPCERT/CC.

The fix was developed by Stephen Henson of the OpenSSL core team partly based
on an original patch from KIKUCHI Masashi.

DTLS recursion flaw (CVE-2014-0221)
====================================

By sending an invalid DTLS handshake to an OpenSSL DTLS client the code
can be made to recurse eventually crashing in a DoS attack.

Only applications using OpenSSL as a DTLS client are affected.

OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m.
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h.

Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue.  This
issue was reported to OpenSSL on 9th May 2014.

The fix was developed by Stephen Henson of the OpenSSL core team.

DTLS invalid fragment vulnerability (CVE-2014-0195)
====================================================

A buffer overrun attack can be triggered by sending invalid DTLS fragments
to an OpenSSL DTLS client or server. This is potentially exploitable to
run arbitrary code on a vulnerable client or server.

Only applications using OpenSSL as a DTLS client or server affected.

OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m.
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h.

Thanks to Jüri Aedla for reporting this issue.  This issue was
reported to OpenSSL on 23rd April 2014 via HP ZDI.

The fix was developed by Stephen Henson of the OpenSSL core team.

SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198)
=================================================================

A flaw in the do_ssl3_write function can allow remote attackers to
cause a denial of service via a NULL pointer dereference.  This flaw
only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is
enabled, which is not the default and not common.

OpenSSL 1.0.0 users should upgrade to 1.0.0m.
OpenSSL 1.0.1 users should upgrade to 1.0.1h.

This issue was reported in public.  The fix was developed by
Matt Caswell of the OpenSSL development team.

SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298)
===============================================================================
 
A race condition in the ssl3_read_bytes function can allow remote
attackers to inject data across sessions or cause a denial of service.
This flaw only affects multithreaded applications using OpenSSL 1.0.0
and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the
default and not common.

OpenSSL 1.0.0 users should upgrade to 1.0.0m.
OpenSSL 1.0.1 users should upgrade to 1.0.1h.

This issue was reported in public.  

Anonymous ECDH denial of service (CVE-2014-3470)
================================================

OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a
denial of service attack.

OpenSSL 0.9.8 users should upgrade to 0.9.8za
OpenSSL 1.0.0 users should upgrade to 1.0.0m.
OpenSSL 1.0.1 users should upgrade to 1.0.1h.

Thanks to Felix Gröbert and Ivan Fratrić at Google for discovering this
issue.  This issue was reported to OpenSSL on 28th May 2014.

The fix was developed by Stephen Henson of the OpenSSL core team.

Other issues
============

OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for
CVE-2014-0076: Fix for the attack described in the paper "Recovering
OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
Reported by Yuval Yarom and Naomi Benger.  This issue was previously
fixed in OpenSSL 1.0.1g.


References
==========

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20140605.txt

Note: the online version of the advisory may be updated with additional
details over time.
'via Blog this'

Saturday, 7 June 2014

How to install CentOS into VirtualBox (Including Guest Additions)

1. Create VM
  • 16GB Dynamic Drive
  • 2 vCPU
  • 2GB RAM
  • PAE
  • 128MB Video
  • 3D Acceleration


2. Install OS
  • Attach DVD Image
  • Start
  • Test Media (Optional)
  • Right-Ctrl is the default host key (to free mouse and keyboard)
  • Basic storage devices
  • Use All Space
  • Desktop Install
  • Create your non-root user
  • Put this user in wheel group so they can use sudo
  • Use su - and then visudo to uncomment wheel group in sudoers


3. Configure network
  • Network cards are unconnected by default
  • Connect using network manager (right-click icon at top of screen and edit connection)
  • If you need to clone VM, remove or edit network card entry in /etc/udev/rules.d/70-persistent-net.rules and remove card in Network Manager


4a. Patch (GUI)
  • You only need to do 4a. or 4b. not both!
  • Need to update before compiling Guest Additions else newly downloaded software will not match existing versions
  • System > Administration > Software Update
  • First update to update the updater
  • Second update to update the OS
  • Reboot


4b. Patch (CLI)
  • sudo yum update
  • Reboot


5a. Add RPMForge repo (GUI)


5b. Add RPMForge repo (CLI)


6a. Install DKMS (GUI)
  • System > Administration > Add/Remove Software
  • Search for dkms
  • Install accepting dependencies


6b. Install DKMS (CLI)
  • sudo yum install dkms


7a. Install development tools (GUI)
  • System > Administration > Add/Remove Software
  • Expand Development and then expand Development tools
  • Select all packages and then apply


7b. Install development tools (CLI)
  • sudo yum groupinstall “Development Tools”


8a. Install Guest Additions (GUI)
  • Insert Guest Additions CD image (Devices > Insert Guest Additions CD Image…)
  • Click Open Autorun Prompt > OK > Run
  • Eject CD
  • Reboot


8b. Install Guest Additions (CLI)


  • Insert Guest Additions CD image (Devices > Insert Guest Additions CD Image…)
  • Cancel pop-up
  • cd /media/VBOXADDITIONS_4.x.xx_xxxxx/
  • sudo ./VBOXLinuxAdditions.run
  • cd /
  • Eject CD

  • Reboot

Fun with file systems

I've identified a need to replicate some file system information in Linux for a number of reasons:

  1. Primary to secondary site for DR purposes
  2. As above but with file locking for limited live-live operation
  3. As above but with record locking for full live-live operation (thinking SAMBA shares here)
I've identified a number of file system features that will let me do this, so I'm going to have a geeky day looking at them:
  1. B-tree file system (BTRFS)
  2. Logical volume manager (LVM)
  3. A. N. Other cluster file system
I think BTRFS is going to be to slow for virtual machines, and LVM has the advantage of running different file systems inside the container sysyem. The might be other options such as rsync but I would really like the solution to be as independent of the applications being replicated as possible (don't want to run rsync in a virtual machine for example).

Any suggestions greatly received, but I'm off to get CentOS in Oracle VM VirtualBox installed for a starting point.