Archive for June, 2011
CentOS OpenVZ – how to secure tmp directory
CentOS Logo
Server administration is a constant battle with security, however there are a few key process that can be done to a server to decrease it’s attack footprint; one of these is to secure the temp directory on your server, which is actually a very simple process. So we will discuss two things here, first why do I need to secure my tmp directory, and finally how do I secure the tmp directory on my Linux server?
The tmp directory (/tmp) is an area on the Linux server that scripts can (as the name suggests) hold temporary files; normally you would expect this to be something such as cached images or database results. However malicious scripts might use this data store to hold some compromising code, with aim to execute it on the system and perhaps install some kind of root kit.
There is a fairly simple fix for this, you can still use the /tmp directory however by creating it as a standalone partition you separate it from the rest of your file system. This will then allow you to define some fairly low level and basic access permissions to block malicious script execution.
Onto to the how, most of my systems at the moment are OpenVZ based virtual servers, unfortunately due to the hypervisor this makes the process slightly more complicated, however just follow the guide below.
NOTE: You will be performing some file system changes here, which are very risky if done incorrectly or are incompatible with your OS. As always I take no responsibility for the results from running these commands, you should always have a full back up, test the process in a lab, and make sure you know what the commands actually do!
First thing that we need to do is open up the fstab file for editing, we are going to use nano for this, however any editor will do the job.
nano -w /etc/fstab
Now we need to create a new line, so navigate to the bottom of the file using your arrow key’s and append the following line, I recommend copying & pasting to ensure you don’t get it wrong.
none /tmp tmpfs nodev,nosuid,noexec 0 0
If you opened using nano you can now close using ctrl+x and then answering “y” to save.
So our changes have been applied to the configuration file, we just now need to remount the temp directory to make the changes become live on the system. Double check the changes before running this command:
mount -o remount /tmp
There is also another temp directory which is wise to secure (/var/tmp dir)
So make a backup (don’t skip this step, you need the files in a bit)
mv /var/tmp /var/tmpfiles
We can now make a link to map /tmp to /var/tmp
ln -s /tmp /var/tmp
Restore the files from the backup you made before
cp /var/tmpfiles/* /tmp/
Restore the files from the backup you made before, and make sure that the files in tmpfiles are now in tmp.
ls /var/tmpfiles ls /var/tmp
If it looks ok, you can remove the tmpfiles directory.
Rm -rf /var/tmpfiles
That’s it! You should now be a bit more secure!
Voice over IP
Voice over IP (Internet Protocol) is an ever expanding market, especially within the corporate or large business area, however within the home or small business there is a very low adoption rate in comparison, especially when you look at none technical users adoption of the technology.
There are many reasons why you could say the implementation of VoIP has been hindered, these range from the cost, to the complexity of setting up a fully working VoIP solution. I do agree with most of these arguments however in reality I believe most of these could be overcome with some improvements in the technology, along with mass production of the hardware to overall reduce costs.
The main reason why VoIP isn’t widely used is the network it’s self, and specifically the quality of service over the network connection been used, controlled by your ISP.
Lets say your home network is on a broadband ADSL2+ connection and you have plenty of free bandwidth on this link, you setup a home VoIP solution and even configure QoS correctly within your house so that voice traffic will always have priority. VoIP traffic within your house is probably going to work great, you can even download/upload torrents etc and there will be zero issues.
However bandwidth isn’t cheap and when you buy broadband you will probably see that you’re going to be placed on a contention ratio, such as 40:1. This contention ratio is a bit like saying between 40 people we are going to allocate 20Mbps of traffic MAX, all of the 40 people will just be left to fight for the traffic as the need it. There are no rules set on this and congestion is going to occur as that’s how the service is designed.
So although the traffic within your house is getting a great service based on your QoS policies, the second you get onto the internet through your ISP’s connection your going to be equal to 39 other people in the ISP QoS policy, if even one of them is using a large amount of traffic for a second or two, your going to start noticing problems with making calls.
Now this doesn’t mean that it wouldn’t work in the future, as broadband networks are just like any other network and most will therefore support some level of QoS, at the moment all of a users traffic is placed into the same profile and therefore treated the same, this is where the problem lies.
If the service provider was to sell you a VoIP solution they would probably use something like dot1p to tag the traffic as ‘voice’ and tag everything else from your router as ‘data’ this profiling and rules would ensure that your voice data is now treated as a normal phone call. Basically the only difference here is that the service provider is reading the QoS values from the client’s router and then using these later in their network.
So why are so many large business using it at the moment? Well for a large company it’s fairly easy as they could just buy two bandwidth links from the ISP and use one for data and the other for voice, or they could buy a dedicated bandwidth link so they are not sharing it with anyone else (contention ratio of 1:1).
Either way your never going to see a wide implementation of VoIP in the home, unless your ISP’s are pushing the solution, as they are the only one who can change the QoS settings on your broadband network!
CentOS Logo
Installing these into windows is generally very easy, just mount the CD or right click on the VM and click install integration components, unfortunately Linux is a bit more complex.
Before we start it’s worth noting that you need to first create the VM as normal, and use the emulated network card so you can connect to the internet and update, plus install the linux development tools. If you don’t have a network connection this will not work.
First we will update the system, install the tools and reboot the VM.
yum update -y yum groupinstall "Development Tools" -y reboot
Now you need to go here and download the file, you should be left with an .iso image, mount this to the virtual machine like normal.
Next we will make a directory to mount the CD image, and then mount the image to this DIR.
mkdir -p /mnt/cdrom mount /dev/cdrom /mnt/cdrom
Next we will copy off all the files we need, and then unmount the DIR.
cp -rp /mnt/cdrom /opt/linux_ic umount /mnt/cdrom
Next navigate to the directory, install the tools and shutdown.
cd /opt/linux_ic ./setup.pl drivers poweroff
Finally remove the network interface and replace with the standard synthetic interface, boot the machine and perform an ifconfig, you should see the new interface there seth0
Go to /etc/sysconfig/network-scripts/ and configure the interface as required.
Note: HSRP is Cisco proprietary, however VRRP also contains similar functionality.
By design all networks should incorporate redundancy throughout, for maximum uptime all equipment within the network should have a redundant replica (or similar hardware) to ensure the network services can still operate after a failure. However this replication would only protect the physical hardware (or medium) from a failure, what about the traffic/software/configuration?
Routing protocols are fairly good when it comes to re-converging a network after a change (failure), as this is what they are designed for, depending on the routing protocol used there will be some inherited limitations such as speed, however in general the network should re-converge around the failure. Protocols such as ether-channel can also be used on the physical (Layer 1/2) links to mitigate any failures there; you may start to see congestion on the network after a failure however the network should still be operational.
HSRP Example
So let’s look at the example image given (to the right), you can see the network is fairly redundant and failure of almost any hardware or physical link should not cause any issues (other than the access ports for the clients).
Now look at the image again and we will say the bottom right PC has a gateway configured for the to right router (B) and the bottom left PC uses the top left (A) router for it’s gateway. So instantly there is an issue, if either of the routers fail one of our PC’s is not going to be able to access any devices out of it’s local network, as there is no ‘route’ out. This is where we use protocols such as HSRP or VRRP to provide what’s called ‘first hop redundancy’, this time there is a virtual address on router A that both of the PC’s will use, if A fails this address will simply come online at router B.
Let’s say that the virtual address is currently on Router A, at once all of the WAN links on this router fail leaving no route out of the network for traffic arriving at that router. However HSRP will still be active on the router as the LAN is correctly working, we are now left with a network that is null routing all traffic. We could use routing protocols to internally sort this out, however that would lead to inefficiently bouncing traffic around the network, and also requiring the timely convergence process to complete.
What we need to do here is track the interfaces; by tracking an interface you can decrement the priority of a HSRP instance by a preconfigured amount. In the most simple example imagine that router A has a priority of 50 and router B has a priority of 49. We will track the WAN interfaces on each router and decrement the HSRP by 20 if the interface fails. Now should the interface fail the layer2 traffic will automatically be failed over to the alternative router – sorted!
Examples coming soon