Author: Jason Mazzota

How to WHM and cPanel Initial Basic Configuration on CentOS 6.7

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


In this guide, we will be reviewing the basic configuration options on first initializing your cPanel & WHM server. It will review some basic areas that may need to be customized by you to get the full experience and your needs out of cPanel & WHM.


A newly provisioned Cloud CentOS 6.7 cPanel & WHM server. If you don’t already have a server, consider a CentOS VPS with WHM from Atlantic.Net.

Initial Configuration of cPanel & WHM on CentOS 6.7

Once you have your cPanel & WHM server provisioned, you will want to log into the server. Upon fresh log in, you should be presented with an End User Agreement license page like the below. After review, click on the blue button “I Agree/Go to Step 2”

Accept License Agreement

License Agreement


On this next page, you will be prompted to set up networking. The first section on this page is the Contact information. This is information so the server knows how to contact you should something go wrong. This section looks like the below and the areas 1, 2, 3, and 4 are described as follows:

Fill in Contact information, SMS address, AIM Name and ICQ Number accordingly.

Contact Information


1. “Server Contact Email Address” – This first area is the server contact email address. This would be the email address the server will email should anything go wrong. It is recommended that you insert a contact address for yourself that you check often. This is a required field.

2. “Server Contact SMS Address” – This is an optional field for putting in a phone or pager email that is capable of receiving SMS.

3. “Server Contact AIM Name” – This is an optional field for using an AIM username for the server to message. It will prompt you for a username and password should you enable this.

4. “Server Contact ICQ Number” – This is an optional field for an ICQ number. It will ask you for the number and password should you enable this.


The next section is the Hostname section which defaults to the below image. For this field, you DO NOT want to use your base domain/website. You will want to use a subdomain of your domain. Something like “server1.domain.tld” or “webserver.domain.tld” where domain.tld is your domain/website. If you do not have a domain, you may make up/create a subdomain but please note that this value will never resolve if there are no DNS records for it. As an additional note, please use a value here that you either have or will create an A record or other type of DNS record for. This will allow you to easily access your server by using that subdomain.

Set your servers FQDN



The third section on this page is for Resolvers. These are important as they handle how your server will resolve traffic and where it will go to do so. These should be left at the default value of and There is not a third resolver for our servers to use.

Input primary and secondary DNS servers


The last section is the Main Network Device. This field should also be left as the default value, as eth0 is the main network device. Once done, you can click on “Save & Go to Step 3.”

Select primary network interface.

Ethernet Device


The next page will be the “Setup IP Addresses” page. You do not have to do anything here unless you have already reserved and assigned an additional IP to this server. If you have not, you may just click “Skip This Step and Use Default Settings.” If you have an additional IP address simply add it to the field and click “Add IP(s)”.

Input IP addresses for which you will be hosting

Setup IP Address


The next page will bring you directly to a Nameservers page. The first box here is Nameserver Configuration. It is important to note that if you are NOT using your server to host your own private or public DNS, you should choose the option “Disabled.” If you are using your own nameservers, pick the nameserver option that best applies to you. In most cases, the default BIND will work for your needs.

If you chose to host your own DNS, select a DNS server to utilize.

Name Server


After this, there is a section for choosing the nameservers that domains on this server will use. If you have your own nameservers for use, you would put these here. DO NOT leave the default values. If you are using our Cloud DNS for your domains, you will want to use and as the picture below shows.

Select the authoritative DNS servers for your domain.

Authoritative DNS

The next section you should leave as is and just click on the “Save & Go to Step 5.”


The next page deals with FTP, mail, and cPHulk services. The first section for FTP, you can leave as the default which is set to Pure-FTPD. If you’d rather use ProFTPD you may do so. If you do not need FTP, you may disable it, but if you plan to upload files it would be best to pick between Pure and Pro FTPD.

Select your preferred FTP server.

FTP Configuration


The next section deals with email and what you want to use for your mail on the server. If you wont be using email, you can disable this, otherwise the default Dovecot is a great choice. You may use Courier if you prefer. There’s also the check box for Convert Mailbox Format. You can leave this checked and is only in play if you are migrating email from another server.

Select your preferred MDA

Mail Configuration


The next sections deal with cPHulk and Perl Modules. cPHulk is brute force protection built into cPanel & WHM. It’s a great idea to enable this and leave it on the default. Remember to add your IP to the whitelist for the service once this configuration is done. The common set of perl modules is used if you will be using perl modules that reference /usr/bin/perl. Otherwise it is not needed. You can click on “Save & Go to Step 6” when done here.

Enable cPHulk brute force protection.



The last page is for Quotas. This page lets you determine if you want to use quotas or not. If you do not, you can not keep track of website’s quotas or email quotas. Once you make your decision, simply click “Finish Setup Wizard” and we are done with the initial setup. This will bring you to the next page called Feature Showcase.

Chose your quote enforment preference.



The first section on the Feature Showcase page deals with Recommended Features. It’s recommended to keep these enabled but it is your choice.

Recommended Features

Recommended Features


After that is the New Features list. These are features you can enable or opt out of. They mainly deal with email. If you would like email clients to store a copy of messages, turn on the Archiving. If you would like users to be able to use Auto Discovery in their mail client for email settings, enable the Auto Discovery option. Query Apache for “nobody” senders is one that we highly recommend is enabled. This will allow you to more easily track down compromised email accounts. We also recommend the SMTP Restrictions options to block compromises. Trust X-PHP-Script should only be used if you’re positive no one on your system will be sending or being compromised. This should rarely be enabled. Once done, click the “Save Settings” button and that will complete all of the configuration necessary to start using cPanel & WHM.

You may chose to enable or disable any neeew features offered by WHM.

New Features

How to: Locked out of cPanel and WHM via cPHulk

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


You have locked yourself out of your server from too many login attempts that have failed either due to a bad password or other means. You know you have cPHulk running on the server and there’s a good possibility it is now blocking you because you did not put your IP in the whitelist. How do you fix it? Follow the steps below!


An Atlantic.Net virtual private server with CentOS 6 and cPanel & WHM.

Unlock yourself from cPHulk

The first thing to do, in this case, is to attempt to disable cPHulk via the web, however, this has a slim chance of working. To do this, append the below onto your web path.


It should look something like:



If that does not work, confirm whether or not you can SSH into your server as root. If you can great! You can run the below command lines via SSH to stop and disable cPHulk and attempt to log into the website version of WHM or cPanel.

If you cannot SSH, try to use the VNC viewer available in the Cloud Portal and log in. If that fails, continue with the below options.

/usr/local/cpanel/etc/init/stopcphulkd/usr/local/cpanel/bin/cphulk_pam_ctl --disable

Find more whm scripts here.

So the Web, SSH, and VNC options did not work for you. Do you have another IP or computer to attempt these options from? You could also try resetting your password via single user mode found here. Contact us for assistance and we will be able to try it from our end.


Once access is regained by disabling cPHulk, remember to immediately add your IP to cPHulk’s whitelist and re-enable cPHulk.

How to: cPHulk Brute Force Protection on cPanel and WHM

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


This guide will take you through using cPHulk brute force protection in cPanel & WHM.


An Atlantic.Net Cloud server with CentOS 6 and cPanel & WHM. If you do not have a virtual private server, why not spin one up from Atlantic.Net in under 30 seconds.

Using cPHulk on cPanel and WHM

The first step to using cPHulk on your cPanel & WHM server is to first log into the WHM side of the server. To do this, you would want to go to https://your_cloud_IP:2087 and log in using your root credentials. Once logged in, on the search bar at the top left (if you can’t find it, it looks like the image below), type “cphulk”. The side list should filter, and you will see a section called “cPHulk Brute Force Protection”. Click on this section to go to the cPHulk options.

Search for CPHulk



The basic cPHulk page looks like the below image. We’ll go over the configuration settings page below.


1. cPHulk state. This will tell you whether or not cPHulk is enabled on your server. You can also disable/enable it here.

2. Clear Failed Logins. This will clear the cPHulk database of failed logins. It’s not recommended unless you need to clear out some failed attempts and someone needs access that is locked out.

3. IP Based Brute Force Protection Period in minutes. This option is for how long an IP is blocked by cPHulk for brute forcing.

4. Brute Force Protection Period in minutes. This is the time period that cPHulk will gather and track failed connection attempts for.

5. Maximum Failures By Account. This is how many times someone can fail within the Brute Force Protection Period before the account is locked.

6. Maximum Failures Per IP. This is how many times someone can fail within the Brute Force Protection Period before the IP is blocked.

7. Maximum Failures Per IP before IP is blocked for two week period. This is self-explanatory. How many times an IP can fail before being blocked for 2 weeks.

8. Send a notification upon successful root login when IP is not whitelisted. The server will send you an email if an IP you have not whitelisted logs into the server as root.

9. Extend account lockout time upon additional authentication failures. This means the more you fail to log in after being blocked, the longer you will be blocked for.

10. Send notification when a brute force user is detected. This will send you an email as soon as cPHulk blocks someone trying to log in.


For the white/black list management page see the below.

White/ Blacklist

White/ Blacklist


1. White List Entry. This will allow you to input an IP or range of IPs into the whitelist. It is recommended that you only add IPs that will be accessing the server that you trust. Mainly your own IP.

2. Black List Entry. This will allow you to input an IP or range of IPs into the blacklist. If you know of an IP or range that you would like to add to the blacklist to stop them from accessing the server, you would enter them here.

3. Edit Whitelist. This will bring you to a new page where you can edit (add/remove) multiple IPs in the whitelist at once. When you are done, you simply click the “Save” button.

4. Edit Blacklist. This will bring you to a new page where you can edit (add/remove) multiple IPs in the blacklist at once. When you are done, you simply click the “Save” button.


The last configuration page is the Login/Brute History Report page. It provides a history of any failed logins or brute force attempts on your server as you can see below.

View login/brute force Report



cPHulk allows for a good amount of customization to help secure your server from failed logins and brute force attempts. It is recommended that you have it enabled and put your IP in the whitelist. If you find that you have locked yourself out of your server via cPHulk, you can view this page on how to remedy the issue.

How to: Password Reset via the Cloud Portal for cPanel & WHM

Jason Mazzota March 24, 2015 by under VPS Hosting 0 Comments
Verified and Tested 3/24/15


This guide will take you through resetting a password on cPanel and WHM via our Cloud Portal.


An Atlantic.Net virtual private server with CentOS 6 and cPanel & WHM.

Password Reset via the Cloud Portal for cPanel & WHM

The first step to do is to follow the password reset guide here. If you are unable to connect with that new password, you will need to connect to the server via SSH or VNC. Once connected, you will need to run via command line:

ALLOW_PASSWORD_CHANGE=1 /scripts/realchpass root 'new_password'

Where new_password is your password you would like to use. Once done, you may now log into WHM as you would normally with the new password. If it still does not work for you, chances are you are blocked by cPHulk and to remedy this, please see this guide here.

You will need to go to WHM’s “Change root password” section under “Server Configuration” like the image below and set the password again. Once done, you have successfully changed the password.

Navigate to WHM's "Change root password" section under "Server Configuration"

Change Root password

How to Remove the Password From Your SSL Key

Jason Mazzota February 8, 2015 by under VPS Hosting 0 Comments
Verified and Tested 2/8/15


This is a fast and simple how-to about removing the password or passphrase from your SSL key file. This tutorial will use OpenSSL for the process.

Removing the password from your SSL Key

To remove the password or passphrase from your .key or SSL key file, you simply need to run:

openssl rsa –in yourSSLkey.key –out yourSSLkeywithnopassword.key

This will prompt you for the password. Once entered, you can use the .key file you just created (yourSSLkeywithnopassword.key) without needing to use a password.

How to Create a pem For Your Existing SSL

Jason Mazzota February 6, 2015 by under VPS Hosting 0 Comments
Verified and Tested 02/05/15


This tutorial will go over how to create a .pem file for your SSL. These .pem files are for use with SSLs and while you do not need a .pem, some processes are made easier by having them and they allow for simple copy and pasting as they are designed to be safe for ascii or rich-text documents. For this tutorial, you will need an SSL, self-signed or Certified by another source, the Intermediate and/or Root CA (if Certified), and the SSL key file. We will also be using OpenSSL.

Creating a pem for your existing SSL

Creating a .pem is very simple. If you did not generate your key file for your SSL as a .pem to begin with, you could do so by running the following type of command. You will need to know what format you created your key file in. These can also be used on any part of your SSL files if you need to do conversion.

Read More

How to Lock Down Your Linux Cloud Server

Verified and Tested 02/05/15


This tutorial will provide you some basic steps to help you lock down and secure your cloud Linux server with Atlantic.Net. By no means do these steps have to be used in order nor do you have to use all of the steps. They are recommendations on securing your server through simple means that take just a little of your time to set up or configure.


For this tutorial, all that’s pre-required is that you have a Linux private cloud hosting with Atlantic.Net.

Securing your Linux Cloud server

Changing the SSH Port

Changing your SSH Port in CentOS

Changing your SSH Port in Ubuntu and Debian


Let’s Limit the root User

Limiting Your root User in CentOS

Limiting Your root User in Ubuntu and Debian



Locking down your CentOS server with IPTables

Locking down your Ubuntu or Debian server with IPTables

IPTables in General


Let’s get those Brute Forcers! Using fail2ban

Basic Use of fail2ban in CentOS

Basic Use of fail2ban in Ubuntu and Debian


Learn more about Atlantic.Net’s hosting services, including HIPAA-complaint cloud hosting.

How to: Securing your Ubuntu or Debian Server with IPTables

Jason Mazzota February 5, 2015 by under VPS Hosting 0 Comments


In this tutorial, we will be covering how to perform some basic IPTables changes that will greatly help secure your server. This is done on a fresh install of Ubuntu 14.04 64bit in our Cloud. This can also be done on any version of our Ubuntu 12.04 OS as well as Debian. All of our commands are run as root and file editing is done via vi. If you are using another user to do this, you will need sudo access. You may use any file editor you would like.

Securing your Cloud server with IPTables

Unfortunately, our Ubuntu 14.04 or 12.04 do not come with IPTables installed already. In Debian, IPTables is already installed so you may skip this. So our first step with Ubuntu is to install IPTables. To do this, simply run:

apt-get install iptables

After installing IPTables, you can check it out by running:

iptables –L

This will list out any rules you have running and verifies for you that you did install iptables and it is working. At this time, it’s just empty but you can see the three types of chains available.

Next, we will install the iptables-persistent package. What this does is it will write out our current IPTables rules to a new file (/etc/iptables/rules.v4) and it will handle automatically applying our rules upon reboot. Pretty helpful!

Sample: /etc/iptables/rules.v4


When you enter the file, it should look like the above picture. There are a few things that we will want to add before our first custom rule. This would be a rule for the loopback interface and one for traffic that is already established. You can see these below. The first custom rule we are going to add will allow SSH access to our server. We’ll want to add the rules above the COMMIT line as COMMIT delimits the end of our INPUT, FORWARD, and OUTPUT ruleset. To find out what all the IPTables segments mean and more information about them, please see our IPTables section.

-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

Note: If you have a custom SSH port like we set up in the Changing your SSH Port in Ubuntu tutorial, you will have to change the 22 to be your SSH port you configured. In our case 3389

Sample: /etc/iptables/rules.v4


Your rules should look similar to the above picture. Now before we finish here, there’s two more things we have to change. Where the rules say:


We will want to make them have:


What this does is it tells IPTables to block and drop all traffic that is not going to ports you specify to allow through. This will stop people trying to break in using services that you have running unless you have opened those ports to the public.

When you’re finished, it should look similar to the above. Once there, just save the file and close it. The last thing we have to do is load these new rules into the current IPTables. To do this, you simply run:

iptables-restore < /etc/iptables/rules.v4

To verify our rules are in place, simply run the same command from earlier:

iptables –L

You should see something similar to the below page.

Sample: /etc/iptables/rules.v4


After this, that’s it! Your new rules are in effect immediately, and they’ll remain through reboots. If you want to get more restrictive with your IPtables, specifically access to SSH, you can do the following for each IP address that should be allowed through. This involves editing the SSH rule and adding more. Where it states the SSH rule we identified earlier, you want to change it to be:

-A INPUT -s IPADDR –m tcp –p tcp --dport 3389 –j ACCEPT

Where IPADDR is your IP address that you want to have SSH access to your server. If you did not set up a custom SSH port, you would want that to remain 22 and not 3389.

To allow specific ports through say for web access to your website, all you need to do is know/find the port the service runs on (or you configured it on) and it’s protocol (TCP or UDP) and allow it through. For example, website access:

-A INPUT -m tcp -p tcp --dport 80 -j ACCEPT

And now the Internet has access to the web hosting you are doing.

Keep in mind, when adding new rules to either INPUT or FORWARD sections, it is a great practice to keep the new rules lumped together with like rules. INPUTs with INPUTs and FORWARDs with FORWARDs. You will also want to make sure that any rules you add that allow a new port through are listed ABOVE any reject statements for that rule set. If they are listed after any reject lines, the rules will not take effect.

To see output of what IPTables is doing and/or blocking with its rules, you can run the below. It will print out the rules you have and anything packet wise about dropping connections or allowing them through.

iptables -L -vn

To find out what all the IPTables segments mean and more information about them, please see our IPTables section (link).

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

How to Limit Root User in CentOS

Jason Mazzota February 5, 2015 by under VPS Hosting 0 Comments
Verified and Tested 02/04/2015


What we’ll be doing in this tutorial is making it so that you can no longer SSH using your root user. This is done on a fresh install of CentOS 6.5 64bit in our Cloud. We will be making a new user on the server to use as our new SSH user, and we will be setting the user up to be a sudo access user. In other words, the new user will be able to access commands as if it were the root user!

Limiting Root user in CentOS

First, we will want to SSH into our server as the root user using your preferred SSH client. Now what we will want to do is run the below command to make a new user and their home directory.

useradd newusername –d /home/newusername

You will want to change newusername to be the new user that you wish to create. After running this, you will need to create a password for the user. You can do this by running:

passwd newusername

note* Remember to always use strong passwords*

Where newusername is the new user you are creating. Now we will want to edit our sudoers file so that our new user can run commands like the root user.


In your sudoers file, you will need to locate the area that has the below information. This is where we will be adding our new user’s rights. In the picture below, it is the location under the green indicator.

Sample Visudo Output

Sample Visudo Output

Right under the root entry, you will want to make the entry:

newusername ALL=(ALL) ALL

Here “newusername” is your new user.

If you don’t know how to edit in vi, you will want to (on your keyboard) hit the Insert button. Then go to the location to add the new user information and type it out. When you are done hit the ESC key on your keyboard and then do “:wq!” to save your changes.

Now the next thing to do… is test the new user! The best way to do this is to either log out or create a new SSH session using that new username and password to log in. Once you log in successfully, we can test your sudo access by going into the SSHD configuration file as the new user. This is because we still have one more change to do to prevent root log in. You can use your favorite editor for this part, we are using vi.

note*To use other commands on the server “as root” you will need to preface it with sudo.*

sudo vi /etc/ssh/sshd_config

This command will open the SSHD configuration file like you are the root user. You will want to locate the “PermiteRootLogin” option indicated by the green indictor in this picture.

Comment out PermitRootLogin sshd_config


You will want to remove the ‘#’ and change yes to no. In the end, the line should look like

PermitRootLogin no

Once done, save and exit the file. Then run:

sudo service sshd restart

You will now be unable to SSH to your server as the root user.

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