Guacamole Server For Home Labs

So you’re an IT pro with a home lab, that’s awesome! Except when you aren’t at home and you can’t get to all of your machines that you need to. Exposing RDP or SSH without multi-factor auth is certainly not something I’d recommend. This is where Guacamole comes in incredibly handy. Guacamole is a web based client that allows you to establish RDP, SSH, and Telnet sessions from within the local network. Port forwarding 8080 for Guacamole allows for outside access thus giving you SSH, RDP, and Telnet access on your local network without exposing your entire home lab to the outside internet.

Here’s the install process:

-Setup a Centos 6 or 7 VM with at least 2 cores and a good 4gb or RAM and a small 10gb drive
-run the following commands below (leverages the script to complete the install of Guacamole and all of its dependancies)

Install Wget
yum install wget -y

Wget the install script
wget http://sourceforge.net/projects/guacamoleinstallscript/files/CentOS/guacamole-install-script.sh

chmod the script to make it executable
sudo chmod 755 guacamole-install-script.sh

Run the script
sudo ./guacamole-install-script.sh

Open a browser and visit the ip or hostname:8080/guacamole

Screen Shot 2016-10-26 at 10.14.41 AM

Once logged in you can see any node groups you created in a tree along with their connections:
Screen Shot 2016-10-26 at 10.14.55 AM

To add additional connections click your username in the top right, choose settings, and then click the connections tab and choose create new connection and fill out the necessary info:

Screen Shot 2016-10-26 at 10.16.51 AM

I’ve been using Guacamole for about 8 months now and it’s great to be able to make changes to my managed switches and access all of my lab machines. I hope this has been a helpful post and that you enjoy Guacamole server!

Image Magick 0 Day Threat

Vulnerability

Image Magick has a potential vulnerability noted by http://www.openwall.com/lists/oss-security/2016/05/03/18

 

Basically in short the exploit allows commands to be run remotely when passed via curl or a URL. To see if you are vulnerable try running the following command on your server:

convert 'https://example.com"| ls "-la' out.png

If you successfully list the directory then you are vulnerable.

 

The Fix

The quick easy fix for this is to adjust your policy.xml file, which depending on version installed will either be in /etc/ImageMagick/policy.xml (in versions 6.6 and newer of ImageMagick or /usr/lib64/ImageMagick/config/policy.xml in versions 6.5.x and older. Simply paste the following in your policymap section:

<policy domain="coder"rights="none"pattern="EPHEMERAL"/>
<policy domain="coder"rights="none"pattern="URL"/>
<policy domain="coder"rights="none"pattern="HTTPS"/>
<policy domain="coder"rights="none"pattern="MVG"/>
<policy domain="coder"rights="none"pattern="MSL"/>

Once you’ve made the necessary adjustments run the test from above again and it should be denied.

Entire Policy.xml

If you need a better contextual example below is a policy.xml file containing the fix:

 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policymap [
<!ELEMENT policymap (policy)+>
<!ELEMENT policy (#PCDATA)>
<!ATTLIST policy domain (delegate|coder|filter|path|resource) #IMPLIED>
<!ATTLIST policy name CDATA #IMPLIED>
<!ATTLIST policy rights CDATA #IMPLIED>
<!ATTLIST policy pattern CDATA #IMPLIED>
<!ATTLIST policy value CDATA #IMPLIED>
]>
<!--
  Configure ImageMagick policies.
  Domains include system, delegate, coder, filter, path, or resource.
  Rights include none, read, write, and execute.  Use | to combine them,
  for example: "read | write" to permit read from, or write to, a path.
  Use a glob expression as a pattern.
  Suppose we do not want users to process MPEG video images:
    <policy domain="delegate" rights="none" pattern="mpeg:decode" />
  Here we do not want users reading images from HTTP:
    <policy domain="coder" rights="none" pattern="HTTP" />
  Lets prevent users from executing any image filters:
    <policy domain="filter" rights="none" pattern="*" />
  The /repository file system is restricted to read only.  We use a glob
  expression to match all paths that start with /repository:
    <policy domain="path" rights="read" pattern="/repository/*" />
  Any large image is cached to disk rather than memory:
    <policy domain="resource" name="area" value="1gb"/>
  Note, resource policies are maximums for each instance of ImageMagick (e.g.
  policy memory limit 1GB, -limit 2GB exceeds policy maximum so memory limit
  is 1GB).
-->
<policymap>
  <!-- <policy domain="system" name="precision" value="6"/> -->
  <!-- <policy domain="resource" name="temporary-path" value="/tmp"/> -->
  <!-- <policy domain="resource" name="memory" value="2GiB"/> -->
  <!-- <policy domain="resource" name="map" value="4GiB"/> -->
  <!-- <policy domain="resource" name="area" value="1gb"/> -->
  <!-- <policy domain="resource" name="disk" value="16eb"/> -->
  <!-- <policy domain="resource" name="file" value="768"/> -->
  <!-- <policy domain="resource" name="thread" value="4"/> -->
  <!-- <policy domain="resource" name="throttle" value="0"/> -->
  <!-- <policy domain="resource" name="time" value="3600"/> -->
  <policy domain="coder" rights="none" pattern="EPHEMERAL" />
  <policy domain="coder" rights="none" pattern="URL" />
  <policy domain="coder" rights="none" pattern="HTTPS" />
  <policy domain="coder" rights="none" pattern="MVG" />
  <policy domain="coder" rights="none" pattern="MSL" />
</policymap>

 

 

Resizing Linux Logical Volumes With LVM

Expanding an Existing Disk

If you are using a virtualization platform such as VMWare/Hyper-V/Xen/KVM/Citrix Xen/etc you will need to shutdown the VM and extend the virtual drive. Once you have finished doing this power the machine back on and do the following:

pvdisplay

This will display the physical volume group and what is currently in it. If you are working with a system that has a single disk you will likely be working off of /dev/sda of /dev/xvda in Citrix Xenserver. We will need to create a new partition on this disk to extend the logical volume in question

fdisk /dev/sda
p
n
p
3
accept default begin block
accept default end block
t
3
8e
p
w
q

The sequence of steps above opens fdisk for /dev/sda. The p denotes the printing of the current partition table, which can be useful to see how many partition numbers there are, usually this will be /dev/sda1 for the boot partition and /dev/sda2 for the filesystem partition. Assuming this is the case pressing n will create a new partition, select p for primary, then select the next available digit (in this case 3 so we can create /dev/sda3). Then accept the default starting block and the default ending block. Once this is complete we need to set the type by pressing t then select the partition number (3) then choose 8e as the identifier for Linux LVM. Once this is done press p to confirm everything looks correct then w to write changes and q to quit.

Once you press w you have committed the changes if you make a mistake press q and try again, this will prevent any erroneous writes from occurring.

At this point we can proceed to extend the volume

partprobe

running partprobe will resync the partition table to the OS so that it can see the new partition, a reboot will do the same thing and may be required if the next step fails, however if possible to avoid a reboot it would be advisable.

pvcreate /dev/sda3

This creates /dev/sda3 as a new physical volume in the physical volume group. Next we will need to see what the volume group name is and then extend the volume group.

vgdisplay

Using the output of the above command we can then extend that volume group. For this example I’ll call it vg_example, yours will be different

vgextend vg_example /dev/sda3

Next we will need to identify the name of your logical volume you wish to extend by running the following command

lvdisplay

Once you have acquired this name we can proceed to the next example. Please note I’ve used lv-root as the name, yours may differ, and I have also used 50Gb as the amount to extend by, please use the correct amount for your use case

lvextend -L +50G /dev/mapper/vg_example/lv-root

Now we have arrived at the final step which is to resize the filesystem

resize2fs /dev/mapper/vg_example/lv-root

If you are using CentOS 7 or another OS that defaults to an XFS filesystem you will need to use xfs_growfs instead of resize2fs

Adding an Additional Disk

If you are working with a physical machine or a VM that you are adding another disk to the process is similar to the above but moderately easier. Assuming the new device we are adding is /dev/sdb, if you are doing this without restarting the machine run partprobe before attempting the below command. If this doesn’t work a reboot may be required.

pvcreate /dev/sdb

This creates /dev/sdb as a new physical volume in the physical volume group. Next we will need to see what the volume group name is and then extend the volume group.

vgdisplay

Using the output of the above command we can then extend that volume group. For this example I’ll call it vg_example, yours will be different

vgextend vg_example /dev/sdb

Next we will need to identify the name of your logical volume you wish to extend by running the following command

lvdisplay

Once you have acquired this name we can proceed to the next example. Please note I’ve used lv-root as the name, yours may differ, and I have also used 50Gb as the amount to extend by, please use the correct amount for your use case

lvextend -L +50G /dev/mapper/vg_example/lv-root

Now we have arrived at the final step which is to resize the filesystem

resize2fs /dev/mapper/vg_example/lv-root

If you are using CentOS 7 or another OS that defaults to an XFS filesystem you will need to use xfs_growfs instead of resize2fs