Author: Jason Mazzota

How to Set up Nameservers via cPanel & WHM

Jason Mazzota August 4, 2015 by under VPS Hosting 0 Comments
Verified and Tested 03/25/2015


This guide will take you through configuring Nameservers on a cPanel & WHM server. These Nameservers will be your name servers and will be usable for your domains. This guide assumes you have already gone through the initial configuration steps for your server and that you can log into WHM. We will be using BIND for our DNS services.


A server with CentOS 6 and cPanel & WHM.  If you do not have a server, consider the industry-leading VPS hosting solutions from Atlantic.Net.

Set up Nameservers via cPanel & WHM

The first step to creating your name servers in cPanel & WHM is to obtain a secondary public IP address and assign it to your server. If you do not know how to do this, you may follow the guide here. It is recommended to reserve 2 IPs for this so that your Nameservers run on their IPs and your websites can run on a third.

The second thing to do is make sure that BIND or your choice of DNS services is enabled. To do this in WHM type “nameserver” in the search bar and go to “Nameserver Selection.” Once there simply look to see if you have a service enabled. If not, we will be using BIND in this tutorial so select BIND and hit “Save.” This will install BIND.

Once the check/installation of DNS services is complete, you will want to make sure you have your website or DNS zone created. You can follow this guide here if you do not know how to make a website or this guide here if you do not know how to make a DNS zone. You only need to do one or the other. If you are hosting your website on this server, then create the website, otherwise if your website is elsewhere, just make the DNS zone.

Once you have the website or zone made, you will need to edit it. To do this type “dns” in the search bar and go to the “Edit DNS Zone.” Once there select the website/zone you will be making the nameservers out of and click on Edit.


Click edit DNS zone


In the edit you will be presented by a page similar to the below image. You will want to scroll down to the “Add New Entries Below this Line” section and insert your values for ns1 and ns2 as A records using your reserved IPs. If you did not reserve 2 IPs, you can use the server’s IP for one of the nameservers and the additional IP you reserved as the second. Once done, click “Save.”


Insert values for ns1 and ns2


If you will be using your own nameservers to host the website they are named after, go back to edit the DNS Zone and edit where it has listed the NS records for your domain to be your new nameservers. Hit “Save” to make the changes.

The last thing to do is if you will be using these nameservers for all websites you will create on this server, go to “Basic cPanel & WHM Setup” and scroll down to the bottom. You will find the Nameservers section and here you will want to put in your new nameservers.

Once done, click on Assign IP address and it should correctly assign the IPs that you have assigned the nameservers. Then click “Save” to save the new changes.


Click Assign IP address on each nameserver


And that is it. You have created your own nameservers and can make websites that can utilize them. Please note that after making your own nameservers, propagation throughout the Internet can take up to 48 hours so do expect some downtime while the nameservers propagate.

Do not forget, in order to use the nameservers, you need to set your domains’ nameservers at the Registrar level to point to the nameservers you have created. This includes the nameservers for the domain the nameservers are made from.

And as a last mention of note. If you would like to have proper nameservers that will not go down, it is recommended to have 2 servers with each server acting as one of the nameservers (you simply make a nameserver the IP of each server or additional IP for each server.) You would just need to replicate your DNS zones between the two servers. This is mainly useful if you will be using your nameservers to host websites that are not contained on the same server as your nameservers.

What is the CVE-2015-2426 Font Driver Vulnerability?

Jason Mazzota July 21, 2015 by under VPS Hosting 0 Comments

On July 20, 2015, Microsoft released a patch (specifically, MS15-078) for a newly announced security vulnerability, named CVE-2015-2426, that affects all supported Windows VPS hosting systems to date. Microsoft has marked this vulnerability as critical and recommends that all servers be patched as soon as possible. The affected Windows versions include:

  • Windows Vista
  • Windows 7
  • Windows 8 and 8.1
  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows RT and RT 8.1
  • Any Server Core Installation


What is the CVE-2015-2426 Font Driver Vulnerability?

This is a vulnerability in Microsoft’s Font Driver that would allow for remote code execution via specially crafted OpenType fonts. These OpenType fonts could be contained in specially formatted documents or embedded in non-secure web pages.


So what does this mean?

Microsoft reserves “critical” for its most severe vulnerabilities. In these cases, an attack can bypass existing security measures. For example, if an email comes to you with a legitimate-looking document for you to open or download, or if you visit a website containing one of these embedded OpenType fonts, an attacker could execute malicious code that could install a keylogger, start network attacks against other people, or encrypt all of your files and demand ransom for the decryption key. Those are just a few of the scary examples of what can be done with remote code execution.


How do I get this fixed?

Update! Microsoft released, via Windows Update, a patch outside of their normal monthly Patch Tuesday cycle. If you just want this specific update, it is labeled KB3079904. If you want to manually apply the update outside of Windows Update, see the TechNet article, and follow their information for direct download links for each Operating System affected.


How does the KB3079904 fix this?

The update changes how Windows Adobe Type Manager Library processes and handles OpenType fonts. Once you apply the update and restart your Windows  device, you will be safe from the vulnerability. For more details on the MS15-078 patch, check out the Microsoft Support article.

How to do a Tomcat to Tomcat SSL Transfer on CentOS

Jason Mazzota June 30, 2015 by under VPS Hosting 0 Comments
Verified and Tested 03/24/2015


In this tutorial, we will be going over a basic way on how to transfer your SSL from one CentOS 6 x86_64 server running Tomcat to another CentOS 6 x86_64 server running Tomcat. This has been tested on Java 6 and Tomcat 6 as well as Java 8 and Tomcat 8. For the ease of this tutorial, the original server with the SSL will be Server A. The new server that we are transferring to will be Server B.


You will need two servers with CentOS 6 x86_64 installed and both servers need to have Java and Tomcat installed. One of the servers has to have an SSL already installed onto it. If you do not have a new CentOS server, you can get a Viritual Private Server from Atlantic.Net.

Tomcat to Tomcat SSL Transfer on CentOS

The easiest way to transfer your certificate between servers is going to be to create a pkcs12 file out of it. Assuming you have the .pem of your certificate, this can be quite easy. If you do not have the .pem, you will need to create one. You can see the Creating a pem for your SSL page for this.

You can copy your key file that you generated for the SSL originally into a separate key.pem if it is not a .pem already. In our example, we have done this and have also stripped out the password for the key. To do this, you may view the How to Remove the Password From Your SSL Key page.

We are now ready to export the SSL to a .pkcs12 file. To do this, on Server A you just run:

openssl pkcs12 –export –name NAME –in certificate.pem –inkey key.pem –out keystore.p12

The keystore.p12 will ask you for a password, please use a secure password you will remember. For NAME, you will want to use a name you will not forget. It would be best practice to simply use your domain name without the .tld (so no .com, .org, etc.) The certificate.pem would be the SSL .pem file you have or just created. The key.pem would be your SSL key in .pem format and they keystore.p12 is what we will be transferring to the new server. You can name all these files as you please, just make sure you are keeping track of them.

Now you may transfer the keystore.p12 to Server B using whatever method you would like. In our example, we use rsync.

rsync keystore.p12 [email protected]_of_Server_B:/directory/to/copy/to

Once copied, you can move the keystore.p12 to your SSL directory of Server B if you did not copy it there to begin with. We will now want to load the keystore.p12 with java’s keytool on Server B.

/path/to/java/keytool –importkeystore –destkeystore /path/to/ssl/directory/keystore.jks –srckeystore /path/to/ssl/directory/keystore.p12 –srcstoretype pkcs12 –alias NAME

It should prompt for a new password for the keystore (you may use the same password or create a new one) and the password you created for keystore.p12. NAME should be the same NAME you utilized in the keystore.p12 generation.

Once this keystore is created, the hard work is done. To finish this off you just need to edit the Tomcat server.xml on Server B to use this keystore.jks and the passphrase and you will be good to go.

Inside the Tomcat server.xml you will want to find the section with: “<Connector port=”8443“.” This is where we would uncomment (remove the “<!–“ and “–>” that section is surrounded in) and add in at the end (before “/>”):

keystoreFile=”/path/to/keystore.jks” keystorePass="PASSWORD"

Where keystore.jks is the keystore.jks we made and the PASSWORD is the password you created for the keystore. After this is added, you can restart Tomcat, and your SSL will be in use for Tomcat.


An example of a tomcat config with the new SSL

You will need further configuration for 8443 to be in use but the SSL will be transferred and if you log into your manager for Tomcat and check the SSL configuration, you should see that SSLs for 8443 are enabled.

How to Configure Apache and Create a Website Configuration on CentOS 6.7

Verified and Tested 08/11/2015


This tutorial will show you how to configure a basic configuration (conf) file for Apache on CentOS 6.7 and create a website. For example, this will show where you can change the web path of your websites, how to assign a public IP to a website, how to enable extensions, and how to allow your site to pick up pages like .php for an index.


A server running CentOS 6.7 and has either Apache 2.2 or LAMP already installed. For information on Apache or LAMP installation, please see this walk-through here.

Read More

How to Install and Use fail2ban in Ubuntu and Debian

Jason Mazzota June 23, 2015 by under VPS Hosting 0 Comments
Verified and Tested 02/17/2015


Fail2ban is a great, wonderful service that is primarily used to stop brute-forcers from accessing your system. Fail2ban works great at deterring your basic attackers away by blocking them when it determines an attack may be happening. We will be performing steps below as the root user. You will need to sudo if you are using another user. For all editing of configuration files, we will be using vi; however, you can use any editor of your choice. This installation is performed on an Ubuntu 14.04 64bit Cloud server with IPTables installed per our IPTables guide. This guide is also applicable to our Ubuntu 12.04 OS and Debian.


An Ubuntu 14.04 64bit server. If you do not have a server and would like one, consider SSD VPS Hosting from Alantic.Net

Install and Use fail2ban in Ubuntu and Debian

Fail2ban is included in the default Ubuntu and Debian repository. All you need to do to install it is run:

apt-get install fail2ban

Once you have installed it, there are only a few changes we need to do to the configuration. The best practice when modifying configuration files like this, is always to copy out the original to a backup. In this case, you can leave the original alone as fail2ban does work with a duplicate .local file also named jail. To do this, simply run:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Once you’ve made that .local file, it’s time to edit it with your editor.

vi /etc/fail2ban/jail.local

Now as you’ll see when editing the file, there are A LOT of sections for you to “play” with and adjust. The main ones we’ll focus on are the ignoreip, bantime, findtime, maxretry, and specifically [ssh] sections.


An example of what the /etc/fail2ban/jail.local file looks like

Note: In Ubuntu 12.04 and Debian, the configuration file looks a bit different from the above. You will only see ignoreip, bantime, and maxretry. The rest of the configuration as far as we are concerned here is the same.

In the picture above, at the green indicator at the top, you will find the ignoreip. The ignoreip is important as you can tell fail2ban to IGNORE your IP address. Setting ignoreip to the correct IP will prevent you from ever locking yourself out of your server by fail2ban. We highly recommend you add your IP address to this field. To add it, all you need to do is add a space after the and put your IP.

Below the green indicator, you will find the bantime. As it states, this is how long a host is banned when triggered for banning. The bantime is the number of seconds that you want that IP address blocked from your system. We recommend that if you are gunning for someone to be blocked, you set this to a high number. The default is 10 minutes. Adding a 0 will make it 6000 seconds or 100 minutes (just over an hour and a half.) That’s a good start.

In Ubuntu 14.04, the next section is the findtime. As it states, this is the span of time fail2ban will look at for failed attempts. The default setting here of 10 minutes (600) is acceptable.

Under the findtime (or bantime in Ubuntu 12.04) you will find the maxretry. As it sounds, this is how many times you’ll be allowed to fail the log in within the findtime before the origin IP gets added to the ban for what you have set the bantime to be. 3 is a great number here to catch someone attempting to get in.

The last section we’ll look at is for [ssh]. You can see the section in the picture below. The biggest thing here to edit is the maxretry (each section can re-write your default maxretry to its own value) and the “port =” section. Maxretry in this means how many times a person can fail attempting SSH to your server before they are blocked. The lower this number, the better, but you also want to be safe to allow some retries, just in case.

In the “port =” section you’ll see the port is set to “ssh”. If you have not changed your SSH port, this is fine. If you have configured a custom SSH port like described in Changing your SSH Port In Ubuntu, you will want to change the port= section. For example, using our custom SSH port:

port = 922

The location on where you can set the ssh port

Now once you have changed this configuration to your liking, all you need to do is save the changes you did and exit the file. Once out, just restart the fail2ban service to activate it.

service fail2ban restart

If you have installed IPTables like in our guide referenced at the beginning, then there is one more step you will need to take. You need to write your IPTables out to the IPTables rules.v4 file to save the changes that fail2ban has implemented. To do this you simply run a:

iptables-save > /etc/iptables/rules.v4

If you check your rules.v4 file, you will see that there is now a rule for fail2ban in place.  This is the rule fail2ban put in place when it was installed and is needed to stop anyone who is blocked by fail2ban.

In the future, when adding new services on the server (like FTP, email, etc) make sure you check your fail2ban configuration!

How to Change the SSH Port in CentOS

Jason Mazzota May 17, 2015 by under VPS Hosting 0 Comments
Verified and Tested 4/21/15


In this how-to we will be showing you how to change your SSH port in CentOS. For the exact operating system, we created a brand new CentOS 6.5 64 bit Cloud server. We will be using the vi editor for our file editing needs. Feel free to download and use any editor that you feel comfortable with.

Believe it or not, one of the simplest things you can do to secure your server is to change the SSH port. Since SSH comes on a default port of 22, you will see a lot of brute force attacks occurring over that port because a lot of users do not change this default SSH port!


A server installed with CentOS 6.5 x86_64.  If you currently do not have a server, please consider VPS Hosting from Atlantic.Net.

Changing your SSH port in CentOS

The first thing we want to do is SSH into our server using your preferred SSH client. Be sure that if you are using a custom user, that you have sudo rights. In this step we will be performing commands as the root user.

Log into Root shell

Root Shell

Once you have logged into the server, let’s open our SSH configuration.

vi /etc/ssh/sshd_config

Now once you are in the configuration you’ll want to look for the section that has “Port” in it. It should be near the top and should be shown as “#Port 22.”

Edit "Port" directive in sshd_config

Sample sshd_config

What we will be doing is removing the ‘#’ so that it is a plain line of “Port 22”. Next we will be changing the 22 in the line to be any number you’d like that another program does not run on. For a list of common ports in use, you can check the following MIT page. In our example, we will be changing the SSH port to 922 so your new line should read:

Port 922

Once you have the change done, simply exit and save the sshd_conf file. Now all you need to run is the below command and it will restart the SSH server. The next time you want to connect via SSH, you will need to do so on your new port, in our case, 922.

service sshd restart

Don’t forget to change the port 22 to your new port in your IPTables when done! You can check out the Locking down your CentOS server with IPTables section (link) for information on how to do that.

Note: *If using Cloud services, You can always access your server via our VNC viewer in the Cloud Portal if you lock yourself out*

Change your SSH Port in Ubuntu and Debian

Jason Mazzota May 17, 2015 by under VPS Hosting 0 Comments
Verified and Tested 4/21/15


In this tutorial, we will be showing you how to change the SSH port in Ubuntu and Debian. For the purposes of this walkthrough, the operating system we created is a brand new Ubuntu 14.04 64 bit Cloud server. This also works in our Ubuntu 12.04 OS as well as our Debian Cloud Servers. We will be using the vi editor for our file editing needs. Feel free to download and use any editor that you feel comfortable with.

Believe it or not, one of the simplest things you can do to secure your server is to change the SSH port. Since SSH defaults to port 22, you will see a lot of brute force attacks occurring over that port as a lot of users do not change this default SSH port.

Read More

How to Create a DNS Zone in cPanel & WHM

Jason Mazzota May 6, 2015 by under VPS Hosting 0 Comments
Verified and Tested 03/25/2015


This tutorial will show you how to create a DNS zone in cPanel & WHM. This is mainly useful for when you have your own nameservers and will be using the server to host the DNS for an off-server website. If you are using our Cloud DNS or not using DNS on your server at all, you do not need to use the DNS zone editor.


A server with cPanel and WHM installed. If you do not have a server already, spin up a cPanel WHM server in under 30 seconds.

Create a DNS Zone in cPanel & WHM

First, you will need to log into WHM for your server. Once you have logged in, go to the search bar and type “DNS.” Proceed to the “Add DNS Zone” section. Here, you will see at the top “Domain Selection.” You’d want to put in the IP of the server or the IP you want the domain to be on and then the domain itself. Once done, you go to “Domain Owner Information” and select the owner for the domain. If this is to be a stand-alone account, you can put it under system ownership. Once done, click “Add Zone.”

Select Add a DNS zone under DNS functions and place your servers IP and domain name followed by "Add zone"

Add a DNS Zone


And that’s it. You can edit the DNS Zone and add more records to it by going to “Edit DNS Zone” and selecting the new zone you made.

How to Fix Automatic Disconnects from WHM & cPanel

Jason Mazzota April 30, 2015 by under VPS Hosting 0 Comments
Verified and Tested 03/24/2015


You have noticed from using your cPanel & WHM server that you are constantly getting disconnected from the Web GUI and not being allowed back in. The following change below will remedy the issue. Please note that cPanel & WHM does have an automatic timeout logout period, but the fix we are applying is when you are actively using cPanel & WHM and are disconnected.


A server with CentOS 6 and cPanel & WHM. If you do not have a server already, you can visit our VPS hosting page and spin a new server up in under 30 seconds.

Fix Automatic Disconnects from WHM & cPanel

The fix is simply changing an option in the settings of WHM. To do this, log into WHM and find the “Tweak Settings” option on the left sidebar. If you do not see it, you may type “tweak” in the search bar and it should filter the left bar so you can see it.

Once in Tweak Settings, you will want to go to the “Security” tab. There, you can find the Cookie IP Validation segment. It should look similar to the below.

Under the Security Setting of Tweak setting, select Cookie IP Validation to Disabled.

Tweak Settings


This defaults to strict. You will want to set it to disabled and then scroll down and hit the “Save” button. This will stop the automatic disconnects you are receiving from WHM.

New York, NY

100 Delawanna Ave, Suite 1

Clifton, NJ 07014

United States

San Francisco, CA

2820 Northwestern Pkwy,

Santa Clara, CA 95051

United States

Dallas, TX

2323 Bryan Street,

Dallas, Texas 75201

United States

Ashburn, VA

1807 Michael Faraday Ct,

Reston, VA 20190

United States

Orlando, FL

440 W Kennedy Blvd, Suite 3

Orlando, FL 32810

United States

Toronto, Canada

20 Pullman Ct, Scarborough,

Ontario M1X 1E4


London, UK

14 Liverpool Road, Slough,

Berkshire SL1 4QZ

United Kingdom