TOP

ownCloud One-Click Install from SolusVM on OpenVZ VPS Accounts

ownCloud One Click InstallDue to popular demand, we have created an OpenVZ OS template based on Centos6 x86_64 that has ownCloud v 4.5 installed with a default version of Apache, PHP5 and SQLite.

Current, or new users can select this template from SolusVM under the “Re-Install” tab. Once completed, all you need to do is login via ssh, start Apache with “service httpd start” command and point your browser to the IP address of your VPS.

Some of the benefits of hosting your own cloud for files (like ownCloud) include:

  • Full control of your files
  • Secure server which you have root access to
  • Privacy
  • Eliminate DropBox
  • More professional
  • Keep your digital rights to photos

What does ownCloud allow me to do?

For starters, you can use it as a secure replacement for DropBox, and you can even password protect the URL’s you send to other users in-case the file is sensitive in nature.

You can upload any kind of file (up to 512MB per file) and access it from the web, through WebDAV, the ownCloud iPhone App, and the Mac OS X/Windows Desktop App.

It is a music player and video streamer (with supported addon enabled).

Bottom Line

You can have full control of your files, share them with your friends or collaborate with your clients if you are a small/medium business owner in a very simple tool.

The benefit of using it on an OpenVZ.ca based VPS, is that you can scale resources as you grow. Start out with the Small VPS package and go beyond the storage of ExtraLarge as you need it.

Read More
TOP

Reducing SPAM on your Postfix Mail Server with the Help of Public RBL/DNSBL Black Lists

A few months ago, we wrote about using “grey listing” on your mail server to help reduce SPAM. While, this concept works great in practice, it does have one major flaw that may affect your users if they are using their mail in time critical environments. Since grey listing initially rejects the mail and waits for a second attempt from the sending mail server to deliver the mail (SPAM servers usually only try one attempt) this eliminates the “instant” delivery of your emails. We all know that emails should never be depended on to be delivered instantly, but these days it’s very close to instant, majority of the time.

As a result, we want to share some other methods on how to reduce incoming SPAM to your mail server and users while preserving the quick delivery so many users count on each day. After all, we live in a world where expectations in technology are consistently rising.

Using a publicly available Black List Database, also known as RBL’s or DNSBL’s (DNS Block List, or Real Time Black Hole List) will allow your mail server to connect and verify whether the sending server is known as a SPAM sender. While there are many different types of Black List’s on the Internet, and we cannot guarantee (nor can they) that they are 100% effective in blocking SPAM, we would like to share a list of the common ones that we have used and are effective.

What to look for in a DNSBL Database

What you want to look for is a well maintained project (since this will be making decisions for you in real time) and one that is well known not to have what are called “False Positives.” In all cases, what you want to avoid when implementing an automated system like this, is the rejection of legitimate email.

DNSBL’s Suggested

The DNSBL’s that we have seen to be effective include the following:

  • zen.spamhaus.org
  • xbl.spamhaus.org
  • rbl.spamhaus.org
  • b.barracudacentral.org
  • bl.spamcop.net

DNSBL’s to Avoid

  • blackholes.five-ten-sg.com

Five-ten-sg.com is very prone to listing entire subnets (up to /24 in some cases) rather that listing individual /32 IP addresses. As a result, using this black list is very prone to attracting false positives and it is not up to date. There are many stale records that we have encountered in this database, sometimes including domains such as Apple’s @me.com and Googles @gmail.com. Avoid this database at all costs.

Implementation

Once you have researched which database (or combination of databases) you want to use, implementing it in postfix is as simple as adding one line for each database you want to include in your main.cf file.

Find the following line in your main.cf file:

smtpd_recipient_restrictions =

Add the following to what is already there:

reject_rbl_client pbl.spamhaus.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client xbl.spamhaus.org,

Again, you can use as many databases you like. In the case of spamhaus.org, it’s best to visit their website to see what the criteria is for getting on to the database (some are more strict than others).

Overall, using a DNSBL is effective in helping with reducing the amount of incoming SPAM on the network. It is a database that works in real time, and there are professionals out there who contribute information to these databases daily to help reduce the amount of SPAM on the public internet.

Read More
TOP

Setup a Tun/Tap OpenVPN Server on OpenVZ in Under 5 Minutes

How can I install a VPN server on my VPS in order to access the internet through it? If you want to skip the background and methodology behind the script, skip to the section called “Installing OpenVPN on OpenVZ.”

One of the pre-requisites to run common PPTP and IPSEC VPN protocols is PPP. Due to the nature of OpenVZ virtualization, it requires it’s own custom version of the Linux Kernel to run. As a result, ppp is not available for us to use.

So, OpenVPN is the simplest way to get a VPN server running on your VPS since it utilizes the TUN interface /dev/net/tun and creates a tunnel to your client software running on your PC. Then, using simple IPTables rules, you can masquerade or NAT your traffic to your public interface. Sounds complicated? to a degree it can be (depending on your linux knowledge level).

So we have come up with  a script that will allow you to install a “simple” version of OpenVPN server and allow you to download the appropriate configuration file (.ovpn & certificate) to import into the OpenVPN client software. This requires no configuration from your side other than running the script and answering some questions in the wizard.

Installing OpenVPN on OpenVZ

The following script will do the following things:

  1. It will check to ensure tun/tap is enabled. If it isn’t you will need to contact your support department and have it enabled before continuing.
  2. It will download and install the RPMForge Repository for CentOS (where OpenVPN packages are located)
  3. It will use YUM and install all the required packages (openvpn openssl openssl-devel)

Once the required packages are installed the script will create a sample easy to use configuration for OpenVPN and put the required files you will need for your Client to connect in /root/openvpn-keys.tgz

It will set OpenVPN to run on boot and create the necessary iptables NAT rules to route your traffic to your primary Public IP address and save it so it will remember when iptables is restarted.

Installation Steps

Download the following script (tested and supported on CentOS 5 32bit) and run as root:  OpenVPN Install Script

or

Type the following commands as root:

cd ~
wget http://www.openvz.ca/scripts/install-openvpn.sh
chmod 700 install-openvpn.sh
./install-openvpn.sh

Wizard Instructions:

  • When asked to enter a “Passphrase” do not enter one, leave it blank and just press “enter”
  • When asked for Country Code, Province, City… These do not have the be accurate. Any values will do.
  • When asked if you want to build/sign the generated certificates enter yes (y).
  • It is normal for it to ask you two times for the same information (Since you are generating both client/server keys)

The final step is to download the /root/openvpn-keys.tgz archive, unzip it on your PC and import the .ovpn file in your OpenVPN Client (you can download it here if you haven’t already). This will create a simple button in your client and allow you to quickly establish a VPN connection to your VPS whenever you need it.

Questions? Contact Us or post a comment on this blog so we can clarify anything not mentioned.

pre-requisites

Read More
TOP

Simple Certificate Based SSH Authentication for your VPS

As a sequel to my first blog post (Simple Ways to Secure the SSH Port on your VPS) I am adding a simple tutorial on how you can setup Certificate based SSH authentication.

The reason someone would implement this method is to avoid using plain-text passwords. This way, anyone who does not have the client-side certificate installed in their SSH client will not be able to login to the VPS.

Overview

There are 3 things that we will need to do in order to get this to work:

  1. Create a Public/Private SSH Key on the Client Computer
  2. Create the Public Key file on the VPS (Server)
  3. Disable password based authentication on the Server

I need to stress at this point, do not do step number 3 before you test a login with the SSH key method or you will potentially loose access to the server entirely and will need to open a ticket with your host!

Step 1

Create an SSH Key Pair (Public/Private) on the client. Type the following commands (do not use root as the user):

$ cd ~/.ssh
$ ssh-keygen -t rsa -b 2048

You will be asked: “Enter file in which to save the key (/home/testuser/.ssh/id_rsa):” Press Enter.

You will then be asked: “Enter passphrase (empty for no passphrase):” Type in a passphrase that you will remember. You will need to enter it every time you ssh to your server from now on.

Note: If you do not enter a passphrase in this step, you will not be asked to enter it when you login to the server. This can be good or bad… It’s good because you can just ssh to the server and login automatically without typing a password. It’s bad because anyone who has a copy of this Private Key will be able to login to your server without a passphrase. So make sure you keep this file in a very safe place if you choose not to use a passphrase.

In your .ssh directory you will see the following 2 new files: ‘id_rsa’ & ‘id_rsa.pub’.

Step 2

SSH to your VPS Server, and go to the .ssh directory in the home directory of the user you want to be able to access with the key. Ex: /home/user1/.ssh

Copy the contents of id_rsa.pub (That you generated in Step 1 on the Client Computer) And paste it in the “authorized_keys” file in your ~/.ssh directory on the Server. Ensure that everything is on one line.

Edit /etc/ssh/sshd_config (You need to be root to do this).

Find the following lines:

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

Remove the “#” symbols next to each of these three lines and save the file.

Restart sshd

Close the session and login to your server again with the user you created the key for.

This time you should be asked for a passphrase (if you entered one in step 1). If you didn’t enter one in step 1 then it should just login and you should have a console $ under the user you created the key for.

Step 3

Once you have confirmed that SSH Key Authentication is working, edit /etc/ssh/sshd_config and find the following line:

PasswordAuthentication yes

Change the ‘yes’ to ‘no’ and restart sshd.

You will now only be able to login with the user you created the Key for. From now on, whenever you want to SSH to the server you will need to make sure that there is a copy of the Private Key in the users Home Directory on the Client Machine.

Read More
TOP

Simple Ways to Secure the SSH Port on your VPS

One of the most important things to do once your VPS has been created is to secure the standard SSH port.

Since SSH is the main method to communicate with any VPS it is the first target for any non-authorized person trying to gain access.

There are a few different ways to add more security to this vulnerable port. You can choose to do one of the following or all of the following depending on your needs.

Change the common port 22

This is the easiest and quickest starting point. Since the default port is 22, most hackers will scan to see if this port is open to start an attack. Changing it to a non-standard port will make it harder to identify where the SSH service is running.

Steps: Login to your VPS through SSH and type the following as root:

vi /etc/ssh/sshd_config

Scroll until you see:

#Port 22
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

Press “i” to enter insert mode in vi and then move to the line that says #port 22. Remove the “#” and specify a different port (example: 22122, 3355 etc…) Make it random but within the acceptible tcp range.

Once this is done, press “escape” then colon (:) and then “x”. Hit enter and this will save your changes.

At the command prompt type (On CentOS):

service sshd restart

On other OS’s you may need to type: /etc/init.d/sshd restart

At this point you may loose connectivity because you changed the port! If you didn’t you will need to exit the current session and reconnect to your server using the new port that you specified.

(Optional) at this point, if your VPS has more than one IP address assigned to it, you can specify only one by changing the “ListenAddress 0.0.0.0” to one of your IP addresses. This way, you can only access SSH through the one interface.

Disable root login through SSH

Using the same methods in step 1 edit /etc/ssh/sshd_config and scroll until you see

#PermitRootLogin yes

Remove the “#” symbol and change the “yes” to “no”, save the file and restart sshd service.

Next time you try to login as root it will deny you.

Note: SSH will still allow you to try and login as root if you specify “root” as the username. It will reject the login even though you specify the right password.

IP Restriction

This step may not appeal to the users who are on Dynamic IP addresses. But it is a very effective way to secure the SSH port even more.

IP restriction will reject a user trying to login from a non specified source IP address. This will allow you to control which hosts will have access and which do not.

If you have many users using your VPS who require SSH access, this is not a good idea as you will block their traffic when implementing this method.

In order to specify the incoming IP address you can use the “/etc/hosts.allow” and “/etc/hosts.deny” files.

Edit “/etc/hosts.deny” and add a line with the following:

sshd:*

This will deny all traffic. Once this is completed you will allow your IP address.

Edit “/etc/hosts.allow” and add a line with your ip address:

sshd: <your ip> (Example: sshd:192.168.1.1)

Note: The allow file will get processed first. So if an ip address matches in the allow file first, traffic will be allowed even if it is specified in the deny file.

Once this is completed the only host that will be able to SSH to your VPS will be the one specified in your hosts.allow file.

Read More