Abused Competence

cPanel Admin Tips & Hints

Automate backups using rsync

Posted on October 27, 2012 by John

Sure, you could use cPanel’s built in backup function to create nice, tidy backups of each user’s account every day – you can even have it FTP those backups to another server of your choice for safe keeping.

That’s not good enough for you, though.  No, you, you live for danger and know that danger can appear around any corner, ready and willing to wipe out things you never thought needed to be backed up, or change too often for a daily backup to suffice.  You need a beefier backup.  You need rsync.

Rsync is a powerful linux tool that basically keeps files and directories insync between two servers.  This is different from a straight backup, as straight backup does not have any comparison functions that are at the core of what gives rsync its power.

I’m going to show you how to setup a second server today as a backup server which will produce a single set of synced files every day to a directory of your choice of the files on your main (Master) server.  This method is ONLY ONE WAY of doing this.  There are many options and features available in rsync which you can tweak to bring the full power of rsync into your machine and have it performing to your exact needs.

REQUIRES: One fully operating cPanel server to act as the Master (the data you want backed up) and One server with a clean CentOS install and lots of free disk space (no servers installed – no Apache, no mail, etc.) to act as the Slave (Backup server).  You can also use a cPanel DNSOnly server as the backup if you want to save resources and you have sufficient disk space – I’ve done this on one server and it works beautifully.
TIME REQUIRED: 30-45 Minutes
DIFFICULTY: Medium-High
DANGER LEVEL: Medium-Low

INSTRUCTIONS

1. LOG IN to WHM as ROOT on your BACKUP (Slave) machine.

2. The first thing we’re going to do is add a user to the system that is allowed to perform the rsync backups.  You don’t want to perform your backups as root and you should choose a username that is difficult to guess.  Don’t use “backup” or “rsync” or “bkup” or anything that might give a potential hacker a toehold on the way in to your system.  Now, type this line, substituting your new backup username as indicated:

/usr/sbin/useradd newusername

3. Just in case anything goes wrong here before we set a password, let’s go ahead and expire the current password on your new user so that a password change will be forced on first login.  Enter this:

/usr/bin/chage -d 0 newusername


4. Now, let’s go ahead and set a password for our new user.  MAKE IT DIFFICULT.  This user will have direct access to copies of files that exist on your main server, so no matter how secure your master machine is, if your backup machine is easily accessible, you’re screwed.  I would suggest a minimum of 12 characters including special characters, uppercase, lowercase, and numbers and not using any human-recognizable words.  Type this and follow the prompt to set your new password:

passwd newusername

5. Next, we need to decide where we’re going to store the backups on the Backup Server’s disk.  NEVER, EVER put the backups in any place where Apache or ANY OTHER public-facing service has access to.  This is a sure recipe for disaster.  For this example, I’m going to place the files in a new folder inside of our new user’s home directory.  This will make the files inaccessible to anyone except ROOT and our new user.  You can put this folder anywhere you like, though.  If you decide to use a location OTHER than the user’s home directory, just change the tilde ‘~’ in the examples below to the root location where your backup folder will be located (e.g., ‘/’ or ‘/backups’)  Let’s first change into our new user for this part.  Type:

su newusername

6.  Tadah!  You are now your new user.  Let’s change to his home directory just to be sure we’re in the right place:

cd ~

7. Now, let’s create the directory to hold our backups.  You can name the directory whatever you want (be sure to include the tilde ‘~’):

mkdir ~/backupdirname

8. We will need to create some keys to be used with SSH when our Master server connects to the backup server.   When rsync tries to connect from Master to Backup, we don’t want it sending a plain text password over the internet where anyone could intercept it.  Instead, we’re going to use an SSH key which is infinitely more secure.  So the first step here is to make a place to put our key information.  Go ahead and enter:

mkdir ~/.ssh

9. And then let’s create an empty file to hold the keys that will be authorized to access our server:

touch ~/.ssh/authorized_keys

10. THIS STEP IS OPTIONAL BUT HIGHLY RECOMMENDED.  Let’s go ahead and close off SSH to ALL users except your new user.   Once you’ve done this no one but newusername will be able to access your server via SSH at all.  (If you want to access the server as root from then on, you’ll need to first log in as newusername and then ‘su’ to change yourself into root):

FIRST TYPE

exit

AND THEN

nano /etc/ssh/sshd_config

AND THEN FIND THE LINE THAT STATES: PermitRootLogin yes AND CHANGE IT TO:

PermitRootLogin no

FINALLY, ADD THIS LINE TO THE VERY END OF THE FILE:

AllowUsers newusername

NOW, SAVE AND EXIT THE FILE AND RUN THIS COMMAND TO RELOAD SSH:

service sshd restart

FINALLY, YOUR NEW ACCOUNT NEEDS TO BE IN THE WHEEL GROUP TO SU TO ROOT LATER:

gpasswd -a newusername wheel

11. Go ahead and log out of SSH on your backup server.  NOW, it’s time to concentrate on our Master server (the cPanel server you want to perform the rsync backup FROM).  Log in to your Master server through SSH as ROOT. (Note: if you were substituting a different directory for the tildes ‘~’ above, you can stop now – the tildes below MUST be used as we are on a different machine now)

12. Let’s change into your key directory (if it doesn’t exist, create it by typing mkdir ~/.ssh):

cd ~/.ssh

13. Let’s check to see if a key already exists.  If you see any printout (it will look like a bunch of nonsense) from this next command, skip to step 15.  If you get a “no such file or directory” message, continue to step 14.

cat ~/.ssh/id_rsa.pub

14. Let’s go ahead and create our key.  Type EACH one of these commands on a SEPARATE line and run them ONE AT A TIME (IF YOU ARE ASKED ANY QUESTIONS, AND THERE MAY BE SEVERAL, JUST HIT ENTER – DO NOT ANSWER THE QUESTIONS!!):

ssh-keygen -t rsa

chmod 700 ~/.ssh

chmod 600 ~/.ssh/id_rsa

15. Now, we need to copy our key to the backup server so it will know to let us in when it is time to do our backups.  We’ll use secure copy for this.  You will need the IP ADDRESS of the BACKUP machine and the newusername password for the BACKUP machine (substitute where indicated) – you may also be asked if you want to continue connecting, just type ‘yes’ as indicated:

scp id_rsa.pub newusername@123.123.123.123:~/

16. Let’s log in remotely to our backup machine from this one to perform some commands (enter the newusername password when asked):

ssh newusername@123.123.123.123

17. Okay, let’s put our keys and info where they go. Type EACH one of these commands on a SEPARATE line and run them ONE AT A TIME:

cat id_rsa.pub >> ~/.ssh/authorized_keys

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

rm id_rsa.pub

exit

18. Okay, that last command just ejected us back to our main cPanel server.  Let’s try it!  Enter this command.  If you are NOT prompted to enter a password, your key setup worked:

ssh newusername@123.123.123.123

19.  If everything went ok, just go ahead and exit the new SSH session you created (if not, re-check every step above and make sure you followed the directions exactly as listed).

20. Now, let’s decide what we’re going to want backed up and when.  Here are some examples to help you put together your rsync command string:

TO SYNC YOUR WHOLE DRIVE (starting at /), INCLUDING ADDITIONS AND DELETIONS (e.g., files added since last backup will be added, files deleted since last backup will be deleted) [command should be all one line - note that there are two dashes - - in front of the word 'delete']:

rsync -a –-delete -e ssh / newusername@123.123.123.123:~/backupdir > /dev/null 2>&1

TO SYNC ONLY YOUR USER’S FILES (starting at /home), INCLUDING ADDITIONS AND DELETIONS, this is the command you want [command should be all on one line - note that there are two dashes - - in front of the word 'delete']:

rsync -a –-delete -e ssh /home newusername@123.123.123.123:~/backupdir > /dev/null 2>&1

TO SYNC ONLY ADDITIONS (e.g., do NOT delete files that were deleted on the Master), simply remove the –delete switch from the above commands. Note that this will not affect changed files, they will still be changed on the backup and you may also find yourself quickly running out of disk space with this option as no files ever get deleted.

TO BACK UP INTO A SUBDIRECTORY  (e.g., use a subdirectory of the main backup directory), simply add the subdirectory to /backupdir (e.g., /backupdir/seconddir).

21.  Now that you’ve decided on the rsync command you’re going to use simply stick it into crontab to run as often as you desire.  For example, to sync all files on the entire disk every morning at 2:00 a.m., just type crontab -e and enter this line at the end (note: the word ‘delete’ has two dashes in front of it ‘–’:

0 2 * * * rsync -a –delete -e ssh / newusername@123.123.123.123:~/backupdir > /dev/null 2>&1

22.  That’s all there is to it!  I would suggest running your first sync at a time when your servers will be really idle – the first one could be a whopper. After that, rsync will intelligently only copy those files that have changed or been added.    Rsync has other options and can perform other functions as well.  For even more information on rsync, see its man page.

Notice that you could add multiple crontab entries to create multiple daily backups into different directories, so you could create rolling backups if you wanted and more.  Pretty much whatever sync or  backup plan you had in mind, rsync will do it for you.

Let me know how you use rsync and if you have any tips, tricks, or tweaks in the way you use rsync by submitted a comment below!

Posted in Backups, Disks and Files | 5 Comments

When SSL goes wacky: ssl_error_rx_record_too_long

Posted on March 14, 2012 by John

As with most cPanel Admins, I have a real SSL Certificate installed at the FQDN of my cPanel server (servername.domainname.com) as a shared certificate so that my users can take advantage of SSL encryption without having to purchase a static IP address and their own certificate.

This works really well…except when cPanel decides to go wonky and suddenly gives this error message when trying to access the secure site (https://servername.domainname.com):

SSL received a record that exceeded the maximum permissible length.
(Error code: ssl_error_rx_record_too_long)

This just happened to me today, in fact.  What causes it?  I’m not exactly sure.  Searching several forums and message boards, many folks seem to think it is caused by account transfers between servers…but I haven’t transferred any accounts in months.  Others say that it happens when you change the IP address of the domain in question…but I hadn’t done that either.  Some have even reported that their fresh cPanel install threw this error at them, so I really wouldn’t be able to say with any certainty WHY it happened.  What I do know, though, is HOW to fix it…well, at least it worked for me…

REQUIRES: Root access and an existing, non-self-signed SSL certificate that was previously installed and WORKING on your server but has suddenly seemed to go wacky or missing by giving the strange error message noted above
TIME REQUIRED: 5 Minutes
DIFFICULTY: Low
DANGER LEVEL: Medium-Low

INSTRUCTIONS

1. LOG IN to WHM as ROOT

2. GO TO SSL/TLS >> Install a SSL Certificate and Setup the Domain

3. In the “domain” box, type the FQDN of the site the SSL certificate was for (servername.domainname.com), the hit the TAB key to move to the next field.

4. Your screen should dim a bit and all of the remaining boxes on the page should fill in automatically.   Make sure the IP address listed matches that of the site the certificate is for, then CHANGE the user field from whatever is listed to the word “nobody” (without the quotes).

5. Click the “Submit” button at the top of the Certificate area and WHM will process your request.  A success message will let you know that everything is done.

6. Browse to your secure website now (https://servername.domainname.com).  If the site pulls up without error and with a secure connection, you are good to go!

If these steps don’t work for you, you may need to obtain the certificate again from your certifying authority and reinstall the certificate manually as if you had never had the SSL certificate set up before.  Those steps, unfortunately, are beyond the scope of this article.

If this easy fix works for you, or even if it simply increases your aggravation without actually fixing anything, let me know in the comments!

Posted in Security & Safety | 2 Comments

How to share access to a mail folder in cPanel – Part 2 of 2

Posted on December 27, 2011 by John

In part one of this article, we went about getting our server ready to share a mail folder.  You see, it seems Bob and Mary in our Accounting Department want to share a mailbox folder so that they can read, insert, and delete mail messages that are common to their department and important to them both.  So, as good SysAdmins, we got our server ready for the task and we’re now going to make the magic happen.

BUT FIRST…and here’s the important part…the MAILBOX FOLDER NEEDS TO ALREADY EXIST. It doesn’t matter who creates it, but one of the parties to the shared folder needs to be it’s owner for the way we are going to implement this shared box.  MAKE SURE THE FOLDER EXISTS or the rest of these instructions will make no sense.

Bob, being the perfect gentleman, went ahead and created the folder under his Inbox for us called “Accounting”.  We will be sharing that one.  Let’s get started:

REQUIRES: Dovecot IMAP Server v1.2, an existing folder to be shared, and all instructions in the FIRST POSThave been followed, knowledge of how to subscribe to folders within the email client of choice
TIME REQUIRED: 30 Minutes
DIFFICULTY: Medium
DANGER LEVEL: Medium-Low

INSTRUCTIONS

1. First, we need to determine the directory where the folder exists, for most installations it will be

/home/cpanelacctname/mail/maildomain.com/mail_username/.name_folder

Where cpanelacctname is the cPanel account that the mail exists under, maildomain.com is the actual domain name that the mail is received at, mail_username is the user name given to the mail user to log into his mail account (without the domain name), and .name_folder is the actual folder that you want to share (NOTE the period in front of the name – you will need that period as that is how Dovecot names folders that exist under the Inbox).

So, for example, if Bob’s business’ cPanel Acct was called acmeco and their domain was bigacmeco.com and Bob’s mail username was,  bobsmith, and we already know the folder is called Accounting, the path would look like this:

/home/acmeco/mail/bigacmeco.com/bobsmith/.Accounting

Keep this path in mind, you’ll need it later!

2. Go to the folder you just determined in STEP 1:
cd /path/to/folder/in/step1

3. Let’s create the ACL file now, by issuing this command:
nano dovecot-acl

4. Now, we define the owner’s (Bob’s) permissions.  Don’t worry what this means, you can change it later.  Add this line into the empty file:
owner lrwstipekxa

5. Now, let’s add Mary’s permissions (since she doesn’t own the folder) – change the red part to suit your actual needs:
user=mary@bigacmeco.com lrwstipekxa

6. Save and Close the file.  We’ve just defined Mary and Bob’s permissions to this folder

7. Now, we need to actually put the folder into Mary’s folder list so she can see it and subscribe to it.  Right now, the system has given her permission, but she can’t see it because it doesn’t exist in her folder list.  So, we need to create a symlink from Bob’s folder to Mary’s inbox.  LOOK AT THIS setup carefully (I’ll give several examples) and construct it as needed based on your file locations (this all goes on one line.  Note the space between the first path and the second path.  Here are THREE examples – use whichever one helps you most:

ln -s /path/to/bob/folder /path/to/mary/folder

ln -s /home/cpanelacctname/mail/maildomain.com/bob_mail_username/.name_folder /home/cpanelacctname/mail/maildomain.com/mary_mail_username/.name_folder

ln -s /home/acmeco/mail/bigacmeco.com/bobsmith/.Accounting /home/acmeco/mail/bigacmeco.com/marydoe/.Accounting

NOTICE in each example that you need to specify the folder name at the end of Mary’s path as well (.Accounting).   This is the most complicated part of the whole setup, so take your time and make sure you get the path right.  ALSO NOTE that the folder name CANNOT ALREADY EXIST in the target (Mary’s) Inbox.  If it does, you will need to name the symlink something else (.Acctg, for example).

8. That should be it for the configuration.  Exit SSH. Now, simply go into Mary’s email client and SUBSCRIBE to the folder you just added for her.  If you don’t know how to do that, see the help file for your mail client or ask your hosting provider how to do that. 

If everything is set up correctly, Bob and Mary will be sharing a folder now and think you are a god. If Fred comes along and joins the department later, you can just follow these instructions again, adding user=fred@bigacmeco.com lrwstipekxa to the dovecot-acl file.

LASTLY, let’s cover that lrwstipekxa part I threw around a bit.  Those seemingly random letters are the actual ACL Permissions that are being assigned to each user.  If, for example, you wanted to give Mary Read access and Write access but she is not allowed to Delete mail from the folder, you’d simply remove the letter “t” from her list of permissions and viola! she cannot delete any longer.  Here’s a full list of the permissions for you to use as you see fit:

 

l – mailbox is visible and can be subscribed to
r – mail can be read
w – flags and keywords can be changed – write access (except seen or deleted)
s – can mark messages as SEEN
t – messages can be DELETED
i – messages can be moved and copied into the folder (INSERT)
p – messages can be inserted in the folder by filter scripts
e – messages can be expunged (i.e., trash emptied)
k – subfolders can be created or renamed (also requires “t” permission)
x – folder can be deleted entirely
a – user has rights to adminster the ACL on the folder

Did I miss anything in this tutorial?  Something that’s not quite clear?  Did it work for you?  Let me know in the comments!

Posted in Email | Leave a comment

How to share access to a mail folder in cPanel – Part 1 of 2

Posted on December 26, 2011 by John

Let’s say Bob and Mary work in Accounting.  They’d like to have a folder in their mail account that they can both access and place important emails that they have received that are relevant to the entire department.  With the normal email configuration, this is not possible.  Bob’s email folders are only accessible by Bob and Mary’s folders are only accessible by Mary.  However, there is a way that you (their System Admin Guardian Angel) can make a folder shared between them both so that they can both add and remove and read from the folder at will without sharing their passwords (a general no-no) and without sharing any of their other, private folders.

I’m splitting this how-to into two parts – the first part (this post) you’ll only have to do one time per server and it basically sets up your server to allow Dovecot ACLs to be used to control folder permissions.  The second part will tell you how to actually share the intended folder. Let’s get started!

REQUIRES: Server root access, Dovecot IMAP Server v1.2
TIME REQUIRED: 10-15 minutes
DIFFICULTY: MEDIUM
DANGER: MEDIUM-LOW

INSTRUCTIONS

1. LOG IN to your SERVER as ROOT

2. Let’s make a local edit file for the Dovecot configuration that cPanel will know overrides the default.  Just issue this command (all on one line):
cp /var/cpanel/templates/dovecot1.2/main.default /var/cpanel/templates/dovecot1.2/main.local

3. Now. let’s edit our new file and make the needed changes.  Issue the command:
nano /var/cpanel/templates/dovecot1.2/main.local

3. Let’s find the section we need by using nano’s search feature.  HIT CTRL-W on your keyboard and then type this EXACTLY (with a space between the mail_plugins and equal sign) and then hit ENTER:
mail_plugins =

4. You should be brought right to the mail plugins line of the configuration file.  You’re going to add “acl imap_acl” to the very end of that line so it looks like this (yours could look slightly different, just be sure to add “acl imap_acl” to the very end of the line):
mail_plugins = [% protocol_imap.mail_plugins %] acl imap_acl

5. Now we’re going to search for the next spot we need to go to in the file.  HIT CTRL-W again and then type this EXACTLY (with the colon and all) and then hit ENTER:
:cache_secs

6. You’ll be brought to the ACL plugin configuration area of the file.  On the very next line or so should be a blank space.  Go to that blank space using your arrow key and then add this line on a line all by itself:
acl = vfile

7. Save and Exit the file.  We’re done with it.  What we just did was turn on the ACL plugin for Dovecot and then tell it we will use the vfile method for controlling ACLs.

8. You can now exit SSH.  Now, go to WHM and log in as root.

9. Go to Service Configuration >> MailServer Configuration.  Do not change anything.  Scroll to the bottom of the page and click “Save Changes“.  This will force cPanel to rebuild the Dovecot configuration file and restart the IMAP Server, which will incorporate the changes you just made (we could also do this at the command line, but this is easier).

10. LOG OUT of WHM.

That’s it!  You’ve just enabled ACLs for your server.

The reason why the ACL plugin is necessary is because, without it, any shared folders would be accessible to anyone on your system with the proper file permission rights to that folder.  The ACL plugin forces Dovecot to check the user’s permissions with the ACL file you’ll create in Step 2 before allowing access.

ONE NOTE: The main.local file that we created is overriding the main cPanel Dovecot Configuration file. Should Dovecot be updated in the future significantly, it could cause problems because any new configuration file will not be loaded.  If this happens, you’ll need to delete the main.local file, and follow these instructions again from the beginning to fix it.

Now, let go to Step 2 where we’ll actually share the mail folder desired!

If you have trouble or comments, as always I welcome your feedback in the comments!

 

Posted in Email | 3 Comments

How to un-ban yourself when cPHulk thinks you’re an intruder

Posted on October 30, 2011 by John

I am a little embarrassed to admit this, but the other day I tried to log in to WHM from an IP address I don’t normally use and attempted to use a password that didn’t go to the root account I was attempting to access.  Needless to say, since I use the built-in cPHulk as my first (but not only) method of brute-force attack protection (as should you), after a few incorrect attempts to log in, WHM banned my IP address completely and I could no longer log in.

Now, normally, I’d be logging in from a whitelisted IP address and I wouldn’t have to worry about this, but I needed to do something urgently on my server and was using a different machine than I normally would to try to get in to WHM.  Since this was urgent, I really needed to get in and couldn’t afford to wait 60 minutes for the ban to be released on the IP address I was connecting from.

What do you do if this happens?  How can you log in when your account is blocked, especially if it is the root account that’s been banned?

After a little searching, I found the answer, and I’m sharing it with you today in case this slightly embarrassing situation ever happens to you…

REQUIRES: Server root access
TIME REQUIRED: 5-10 minutes
DIFFICULTY: LOW
DANGER: LOW

INSTRUCTIONS
1. Log in to your server via SSH as root.  This should still be allowed because cPHulk blocks access to cPanel/WHM, not the server shell itself.  (If another product such as the awesome csf/lfd firewall product has blocked you, however, you may not be so lucky)

2. Issue this command at the prompt:
/usr/local/cpanel/etc/init/stopcphulkd

3. Leave the SSH session open and go to your browser.  You should now be able to log in through WHM.  Log in to WHM as root.

4. From the main screen of WHM click “Security Center”, then click “cPHulk Brute Force Protection”, then click “Flush DB”.  This action will clear out all IP address bans currently in effect with cPHulk.  Alternately, you could click on “White/Black List Management” and then “Edit Blacklist” to find and remove only your IP address, but the first method is the easiest unless you know you are actively under attack by a would-be intruder.

5. Log out of WHM and go back to your SSH session that you left open in step 3.  Issue this command at the prompt:
/usr/local/cpanel/etc/init/startcphulkd

6. Try and Log In to WHM again.  You should be able to with no problem and your system is still secure against brute-force attacks from others.  If you’ll be using this IP address in the future to connect to WHM and the IP address is in a secure, non-public place, you might want to add the IP address to your cPHulk whitelist so this doesn’t happen again in the future.  To do this, go to Security Center -> cPHulk Brute Force Protection -> White/Black List Management -> Edit Whitelist.  You should be prompted near the top to add your current IP to the list.  Click where indicated and you should be all set!

What you did in the instructions above was to simply stop the cPHulk service from running.  With it disabled, you could safely log in to WHM again without being blocked.  You then removed the instructions that told cPHulk that your IP Address was an “intruder” by “flushing” the database.  Finally, you restarted the cPHulk service so it could begin protecting you from would-be intruders again, sans your IP address.  You were then able to log in again.

While it can be frustrating and a bit humbling to be banned from your own system, it is good to know that your system is doing its job properly and that you can easily fix your permission problem with a little easy command-line work.

Have you ever been banned from your own system by strict security rules before?  How did you cope with the computer-generated wrist-slap?  Let us know by commenting below!

 

Posted in Security & Safety, SSH | 4 Comments

How to copy or clone a package or feature set

Posted on October 3, 2011 by John

As you know, you can create packages for setting up new accounts in cPanel by going into WHM and going to Packages -> Add a Package.  You can even tweak which options are turned on or off for your end users by going to Packages -> Feature Manager.  But if you’ve ever wanted to copy a package or feature set so that you can use it on another package or account or use it as a template for  a new package or feature set, you probably think you’re out of luck.

Not so.  You can easily clone packages and feature sets or copy them to a cPanel reseller account with just a little command-line magic:

REQUIRES: WHM/cPanel root access and an already set up package and/or feature set that you want to copy
TIME REQUIRED: 5-15 minutes
DIFFICULTY: LOW
DANGER: LOW

INSTRUCTIONS

1. Write down the exact name of the package or feature list you want to copy, including all underscores, if any. We’ll refer to this as writtenfilename in a little while.  If you will be copying this package/list to an account other than “root”, write down the user ID of the account to copy to (note that this account must be a reseller in WHM). We’ll refer to this user ID at writtenID in a little while.

2. Log in via SSH to your cPanel server as root.

3. To clone/copy a PACKAGE, do this first, then skip to step 5:
cd /var/cpanel/packages

4. To clone/copy a FEATURE SET, do this first, then proceed to step 5:
cd /var/cpanel/features

5. To simply clone the package/feature set and give the clone a new name, do this and skip to step 7 (replace the italicized portion with the one you wrote down in step 1):
cp writtenfilename newname

6. To copy the package/feature set to another account, do this and then proceed to step 7 (replace the italicized portions with those you wrote down in step 1):
cp writtenfilename writtenID_writtenfilename

7. Log Out of SSH

Yep, it’s really that simple!  CPanel keeps packages and feature sets in simple text files on the server.  Any file that begins with a user name followed by “_” (underscore) before the package name will automatically show up in that user’s reseller WHM package/feature set list.  Any file that does not have a preceeding user name will only show up for the root account.

Do you know of any other package/feature list tips or tricks?  Share with everyone in the comments!

Posted in cPanel Interface, User Administration | Leave a comment

Setting up a cPanel DNSONLY Server – Part 2

Posted on July 9, 2011 by John

Okay, so you’ve decided to set up a secondary DNS server for your cPanel boxes using the free DNSONLY product from cPanel.  You’ve read and followed the instructions in Part 1 of this article.  Now, you’re ready to put all of your cPanel machines in a neat little cluster so your DNS zones will automatically sync themselves with your secondary DNS server.  Let’s get started!

REQUIRES: one (1) cPanel DNSONLY server, freshly setup according to these instructions and at least one (1) full cPanel server that you wish to sync with your DNSONLY server.
TIME REQUIRED: 30-45 minutes
DIFFICULTY: MEDIUM-HIGH
DANGER: MEDIUM-LOW

INSTRUCTIONS

1. First, let’s configure your newly set up DNSONLY server. In your Web Browser, go to http://xxx.xxx.xxx.xxx:2086 (replace the xxx.xxx.xxx.xxx with your DNSONLY server’s IP Address) and log in to your DNSONLY server as root.

2. From the WHM Main screen, click “Cluster/Remote Access“ and then click “Configure Cluster“.  Change the setting from “Disable Dns Clustering” to “Enable DNS Clustering” and click “Change“.

3. Go back to the Main WHM Screen and go to “Cluster/Remote Acess” -> “Setup Remote Access Key“.  Under “Current Access Key” select the ENTIRE CONTENTS of the User: box, right click on your selection and then click “Copy“ to copy the access key to your clipboard.

4.  Okay, now it’s time to sync your full cPanel server to the DNSONLY server!  In your browser, log in as root to your full cPanel web server’s WHM control panel (http://yourdomain.com:2086 or https://yourdomain.com:2087).  From here out, I’ll call this full cPanel server the “Production Server”.

5. Now, from your Production Server’s WHM Main Screen go to “Cluster/Remote Access” -> “Configure Cluster“.  Click “Enable Dns Clustering“ just like you did in step 18 and click “Change“.  You’ll get a success message; just click “Return to Cluster Status” to be brought back to the configuration screen.

6. Scroll down to “Add a new server to the cluster“.  Make sure “cPanel” is selected in the dropdown box.  Click “Configure“.

7. Now comes the important part.  You’ll need to perform several critical steps in order to setup the sync correctly: (1) In the box labeled “:“, enter the IP Address of your DNSONLY server.  (2) In the box labeled “Remote server user name:“, enter “root” (without the quotes). (3) In the large empty box labeled: “Remote server access hash:”, click inside the empty box, then right-click and choose “Paste” to paste in the access key you copied in step 3 above. (4) Under the large box, make sure that “Setup Reverse Trust Relationship” is CHECKED and that “Debug mode” is UNCHECKED. (5) Next to “DNS role:”, open the dropdown box and select “Synchronize Changes“. (6) Click “Submit“.  cPanel will connect to the DNSONLY server now and set up all necessary access and synchronization. You should get some green little checkmarks on the next screen along with some happy little messages.  Congratulations, your Production Server is now clustered with the DNSONLY server…but you’re not done yet!

8. Now, your Production Server is linked up and all of your DNS zones will instantly be replicated on your DNSONLY server.  This won’t do you any good, though, unless you set the actual DNS for your domains to let the world know that the DNSONLY server exists and can serve requests for your domain.  Let’s do that now.  Start by going to WHM -> “DNS Functions” -> “Edit DNS Zone“.

9. I’m not going to go into detail here because this is where your own preferences and needs as an administrator come into play, but for each zone that has its own private nameserver A entries (A entries for ns1, ns2, etc.), you will need to Edit that zone and change the “A” entry for “ns2″ to the IP ADDRESS of your DNSONLY server (you could also add an ns3 entry, or ns4, etc., instead of changing the ns2 entry, but that is all up to you).  If you need help with this step, contact your hosting provider.

10. Once you have edited all the DNS zones needing updates, you will now need to go to your domain registrar (GoDaddy, Namecheap, 1&1, etc.) for any domain that you edited in the last step (domains with their own private nameservers) and update the hostname (Nameserver Registration) entry of ns2 (or ns3 or ns4 or whatever you called it) to now point to the IP address of the DNSONLY server.  If you need help with this, contact your domain registrar.

11. Now, if you added a new Nameserver entry into your zonefiles in the last steps that didn’t already exist (like ns3 or ns4, etc.), you’ll need to edit in WHM each and every zone that you want to be able to use the DNSONLY server for resolution.  Simply add an “NS” entry into each zone for the new nameserver’s domain name.  Again, if you need help with this, contact your hosting provider.

12.  Finally, if you want all new domains from here on that you set up on your Production Server to include NS entries for the new nameserver, you’ll need to go into WHM and go to “Server Configuration” -> “Basic cPanel & WHM Setup” and scroll all the way down to the bottom of the page to the “Nameservers” section and add the desired NS entry in the necessary blank (e.g., ns3.mydomain.com).  If the NS entry already exists, just leave it alone.

13. AT LAST – everything should be set up correctly now!  All that’s left to do now is to test your setup.  In your web browser, go to http://legacy.zoneedit.com/lookup.html and enter your Production Server’s full domain name (www.mydomain.com) in box 1 and the IP address of your DNSONLY server in box 3.  Run the lookup, and if you get the correct IP address for your Production Server in return, your server is working properly!

NOTE: If you have more than one cPanel server that you want to cluster with the DNSONLY server, simply follow steps 4-13 with each additional server after setting up the first one.

Whew!  I’ll admit, this isn’t exactly an easy process and domain resolution with clustered servers can be a confusing, convulated mess sometimes.  Hopefully, though, these articles made the process just a tiny bit easier and you now have a shiny new DNS backup server running for your cPanel box.

As always, if you have questions or comments or suggestions, just let me know by posting a comment below!

Posted in Backups, DNS | 3 Comments

Setting up a cPanel DNSONLY server – Part 1

Posted on July 8, 2011 by John

Current best practice for DNS server assignment for any internet domain dictates that you must have at least two physically separate and geographically disperse domain name servers handling requests for your internet servers.

In plain language, this means that, though it isn’t technically “required”, you should always have at least two DNS servers that are nowhere near each other serving DNS requests for your internet servers.  Nothing earth shattering will happen if you don’t do this (and many large-scale low-cost web hosting providers don’t follow the “two separate name servers” rule), but in the event that your name server goes down, no one will be able to find your server or any backup services that may be available because the domain name would no longer resolve.  A second, separate nameserver answering queries for your domains would fix this…and cPanel lets its customers set this up on their own secondary server for FREE with a product called cPanel DNSONLY.

As the name implies, cPanel DNSONLY is a stripped-down, bare-bones version of cPanel that ONLY handles replicating your other cPanel servers’ DNS zones. Today, I’ll show you how to set up a fresh, clean cPanel DNSONLY server and then, in Part 2, configure your other cPanel servers to replicate its zones to the DNSONLY box.

The best part is, this lighter version of cPanel uses less resources than its full-fledged siblings, and DNS itself needs very little horsepower to function properly, so a cheap, budget VPS provider should be able to provide a decent VPS to host cPanel DNSONLY for just a few bucks a month.  On my testing server, for instance, cPanel DNSONLY uses less than 2 GB of disk space and under 275 MB of memory.

This first of two articles deals with installing the DNSONLY server itself.  We’ll handle actually configuring your server clusters in Part 2.  So, are you ready to install DNSONLY and set up your server cluster?  Let’s get started!

REQUIRES: a fresh, clean CentOS install on an unused VPS instance or Dedicated box.
TIME REQUIRED: 2-3 hours
DIFFICULTY: MEDIUM
DANGER: LOW

INSTRUCTIONS

1. Start with a fresh, clean CentOS install.  If you have a VPS, simply choose to “Reinstall” the Operating System from your VPS Control Panel and choose CentOS from the available OS images (VPS control panels vary greatly – yours may not be labeled as clearly – if you need help, contact your VPS provider’s Help Desk).

2. LOG IN through SSH as root.

3. Let’s first set your hostname for the install (the fully qualified domain name that you want to use for this DNSONLY server: e.g., dns.example.com):
hostname dns.example.com

4. Let’s install some necessary utilities to make this as painless as possible.  just enter:
yum -y install screen rdate perl

5. Okay, now let’s make sure we don’t have anything installed that will interfere with the installation.  Enter this (all on one line) – you may be required to answer yes to confirm removal of the packages:

yum groupremove "FTP Server" "GNOME Desktop 
Environment" "KDE (K Desktop Environment)" "Mail 
Server" "Mono" "Web Server" "X Window System"

6. Move to your home directory now by entering
cd /home

7. Now, let’s download the installer for cPanel DNSONLY:
wget -N http://httpupdate.cpanel.net/latest-dnsonly

8. Okay, before we install, let’s run the “screen” utility so we can reconnect if we should accidentally get disconnected from our SSH session (to reconnect, just SSH back in, log in as root, and type “screen -r” at the command prompt):
screen

9. Okay, let’s start the installer:
sh latest-dnsonly

10. Now comes the easy (and boring part): cPanel will do all the hard work for you, installing cPanel DNSONLY.  This will take about 60-90 minutes even on a relatively fast machine, so you can go do something else for a while.

11. Once the installation is finished, you’ll be returned to the command prompt.  Now that cPanel DNSONLY is installed, you can go ahead and exit both the screen utility and SSH by typing
exit
and then again:
exit

12. Now, let’s go into WHM now and configure our new server.  In your WEB BROWSER, go to (replace xxx.xxx.xxx.xxx with your DNSONLY server’s IP Address):
http://xxx.xxx.xxx.xxx:2086

13. At the prompt, log in with user name of “root” and your root password.

14. Read and Accept the license agreement on the page that comes up.

15. On the next page, fill in your contact information and verify the FQDN (fully qualified domain name)  of your DNSONLY server, then click “Save and Go to Step 3” (leave the rest of the page alone unless you know what you are doing)

16. A list of your IP addresses on this server will be shown. Unless you know what you are doing, just leave this alone click “Go To Step 4“.

17. Select the nameservers for the server itself.  This is usually ns1 and ns2 of the box’s domain (ns1.yourdomain.com, ns2.yourdomain.com) and are usually pre-filled for you, but the choice is up to you if you know what you are doing.  Check off both boxes for “Add A Entries” at the bottom and fill in the DNSONLY server’s IP address for both ns1 and ns2 – this may be pre-filled for you as well. (NOTE: You could also synchronize this server with yet another server, but that is beyond the scope of this article). Lastly, click “Finish Wizard“ to complete the initial setup.

That’s it!  You now have a working cPanel DNSONLY server!  It won’t do much right now, but in PART 2 of this article, I’ll walk you through setting up your server clusters so your cPanel machines can begin synching their records with your shiny new DNSONLY server.

FINAL NOTE:  I would STRONGLY suggest that you install a firewall product, such as csf/lfd, on this server as well as change the default SSH port to keep your server as secure as possible from nasties.  As it happens, I’ve already written two instructional articles to walk you through those steps as well – just click the links!

How did your cPanel DNSONLY install go?  Did you need to do anything additional to get it to work that I didn’t list?  Let me know in the comments!

Posted in DNS, Installation & Configuration | 6 Comments

How to change the default SSH Port for added security on your server

Posted on July 7, 2011 by John

By default, SSH runs on port 22.  Running SSH on port 22, though, makes it an easy target for those who might try to brute-force their way into your server and do all sorts of evil things with it.  Removing SSH from Port 22 and making it run on a different, unusual and hard-to-guess port, like, say, 61612 for instance, will increase the security of your server by making it appear to a bot or lazy port-scanner that you don’t have SSH running at all.  Of course, this won’t stop those determined to find the port that your SSH is running on, but it will immediately cut out those hackers who aren’t that invested in your machine in particular, but are looking instead for easy “ins”.

Let me make it clear that just changing SSH’s port alone will not make your server invincible; it’s just one good practice that you should employ along with all of your other security tools.  You still need a good, solid firewall product running on your system, long and difficult passwords (or use key authentication instead for even more security), and all the usual server hardening and good coding practices that keep your server as safe as possible from outside attack.

That said, let’s go ahead and move SSH onto another port:

REQUIRES: A working cPanel install with SSH currently running on Port 22
DIFFICULTY: Medium-Low
ROOT REQUIRED: Yes
TIME REQUIRED: 30 Minutes
DANGER LEVEL: Medium-Low

INSTRUCTIONS

1. First, let’s pick what port you want to move SSH onto.  You can pick any UNUSED number between 1 and 65535. If the port is or could be already in use on your server, you cannot use the port number.  For a list of commonly used ports that you should avoid, see this list at Wikipedia.  Your best bet is to choose a number in the unregistered range (49152-65535), like 61612.  Once you’ve chosen your port number, you’re ready to put it to work:

2. Log In through SSH as root to your server.

3. The SSH service is called sshd in CentOS, so let’s open sshd’s configuration file so we can edit it (I use nano, but you can use vi or whatever text editor you like):
nano /etc/ssh/sshd_config

4. Near the top of the file you should see a line that says either “#Port 22″ or “Port 22″.  If you don’t see this line at all anywhere in the file, that’s okay too – just insert the line below as directed in this step.  If the Port line is already in the file, however, go ahead and DELETE THE LINE.  In it’s place put the following (substitute xxxx with the port number you picked in step 1):
Port xxxx

5. Go ahead and save and close the file you just edited and run the following command to restart sshd and take advantage of your new port assignment:
service sshd restart

6. Exit out of SSH to close the current session:
exit

7. Now, let’s test out the new configuration.  First, try to log in on Port 22 through SSH.  If it fails to connect (“Connection Refused”), you’ve successfully removed SSH from Port 22.  Next, try to log in to SSH using your new Port number.  If you connect successfully, congratulations!  You’ve successfully moved SSH onto a non-standard port and your server is just a tad safer for it! IF IT DOESN’T WORK, see step 8.

8. If your new SSH port is working, you’re done – skip this step!  If something went horribly wrong, though, while you were attempting to change the default SSH port and now you can’t log in to SSH at all, don’t worry!  cPanel has a built-in magical script to reset SSH back to port 22 so you can log in and try again.  Once you’ve used this script, though, you must log in to SSH immediately and edit the file listed in Step 3 or the port will be reverted again the next time sshd restarts.  Here’s the script you need:  in your web browser, go to this address (substitute xxx.xxx.xxx.xxx with your server’s IP address) and log in as root (you may be asked for your password twice):
http://xxx.xxx.xxx.xxx:2086/scripts2/doautofixer?autofix=safesshrestart

FINAL NOTE:  If you already had a firewall product, such as csf/lfd installed on your server before making this change, you will now need to go into the configuration for that firewall and “open” the port for incoming traffic that you just moved SSH onto as well as “close” Port 22 to incoming traffic entirely.  Refer to your firewall vendor for instructions, or ask your hosting provider if you need help with this.

What other things have you done to make your cPanel server more secure?  Do you think this common precaution is effective against modern intruders?  Let us know by leaving a comment!

Posted in Security & Safety, SSH | Leave a comment

Install csf for a solid firewall on your cPanel server

Posted on April 22, 2011 by John

One of the first things you’ll no doubt realize as you begin down the path of learning to be a cPanel system administrator is that your server seems to be pretty much constantly under attack.  There are nefarious types all over the world who would just love to turn your little server into their instrument for untold mayhem.  Most of the time, these so-called “attackers” are just checking for vulnerabilities that they can exploit in your server, not targeting you specifically, so it is really important to keep your cPanel and OS up to date, keep the safest practical cPanel settings active,  and practice safe scripting and coding techniques for items running on your server.  Beyond that, though, there are other ways that thugs and villains can get into your system, and so one of the very first things that I believe everyone needs to do after they’ve got cPanel up and running on their new server is to set up a good firewall and log monitoring system to protect against the most common types of internet nasties.

One product I have installed on all of my cPanel servers, really love, and highly recommend is the free and oft-touted ConfigServer Security & Firewall, also known as “csf” and/or “csf/lfd”.  This firewall is rock-solid, is designed specifically to work with cPanel right off the bat, and includes an awesome additional component called “lfd” or “Login Failure Daemon” that constantly monitors your log files and automatically (yes, automatically) blocks offending IP addresses that try to hack their way into your system.   This product is top-notch, uses minimal resources when running, and is free- I believe that no cPanel server should be without it.

So, if you don’t already have a firewall installed on your cPanel server, now’s the time to do it, and today we’re learning how:

REQUIRES: A firewall-less cPanel install (cPanel does not install a firewall by default, so if you have a default install, you should be okay.)
DIFFICULTY: Medium-Low
ROOT REQUIRED: Yes
TIME REQUIRED: 30 Minutes
DANGER LEVEL: Medium-Low

NOTE: Be careful to make sure that you have NO OTHER firewall installed on your server before installing csf.  Having two firewalls running at the same time is a recipe for problems and could make your server unstable or unusable.  If you don’t know, ask your VPS/dedicated hosting provider- some of them actually install csf with cPanel initially, so you’d already be set!

INSTRUCTIONS

1. LOG IN as root to your server via SSH.

2.Let’s make sure you’re in the root home directory just to keep things clean:
cd ~

3. Now, let’s download the csf package for install- this should only take a few seconds at most:
wget http://www.configserver.com/free/csf.tgz

4. Now, let’s unpack the tarball so we can work with it:
tar -xvzf csf.tgz

5. Okay, let’s change into the directory that was just created:
cd csf

6. We now need to run the install script for csf – it will only take a few seconds:
sh install.sh

7. Once that completes, you should see “Installation Completed” at the bottom of the text that flew by on your screen during step 6.  Now, run this little test script:
perl ~/csf/csftest.pl

8. At the bottom of the output that flies by on your screen from Step 7, look for the “RESULT:” section.  As long as it says that “…csf will function…” or something similar, you are okay.  Note that on some VPS servers, you may get a message like the following and it is also okay – it’s caused by the virtualization of the hardware your server is on and it won’t affect the major operation of csf/lfd: “csf will function on this server but some features will not work due to some missing iptables modules“.

NOTE: If you DON’T get a result that indicated csf will function, you will need to either fix the errors presented or uninstall csf.  You may need to contact your VPS/dedicated provider to help you resolve.  Most people shouldn’t have a problem, though- I’ve installed csf now on three different servers and I haven’t had a single problem at all.

9. Okay, csf is now installed and running properly, but it is now in a special “test” mode to allow you to configure the firewall and play around with settings without accidentally locking yourself out permanently.  In the test mode, if you accidentally get yourself blocked on the firewall somehow, csf will automatically unblock any blocked addresses (including yours) every few minutes.  Also, you should know that the csf install process automatically detected and has already opened up all of the ports that you need to run a default cPanel server (cpanel/whm port, ftp, http, mail, etc.) – even including if you are running exim on a second port or if you’ve changed the default sshd port (how cool is that?).  So, now is the time to test your system.  Make sure you can connect to every service you or your clients need (using a computer other than the server itself).  This includes ftp, mail (in and out), http, cpanel, whm, etc.  Once you are satisfied that all is well, it’s time to turn test mode off.  Let’s go to our web browsers now:

10. LOG IN to WHM as root and go to Plugins -> ConfigServer Security & Firewall.

11. The csf main interface will display and you’ll see a bunch of buttons in several sections.  Look under the section labeled “csf – ConfigServer Firewall“, and then click “Firewall Configuration.”

12. You’ll now see the csf configuration file – and boy, is it a whopper!  Don’t be overwhelmed, though; most of the settings are configured already for you for optimal use under default conditions and there are only a few places you may ever need to change.  However, these two particular settings are the ones you’ll probably use the most, so I’ll point them out:

TCP_IN – this is a comma-delimited list of ports that you want OPEN for INCOMING connections to your server.  If you’re ever asked or need to “open an incoming port,” this is the place to do it.  Simply add the additional port on the end of the line with a comma in front (e.g., ” ,2121 “)

TCP_OUT – this is a comma-delimited list of ports that you want OPEN for OUTGOING connections.  Just as with TCP_IN, you change this as necessary to allow for outgoing connections from your server to the world.

13. NOTE: IF YOU MADE CHANGES TO ANY SETTINGS in the csf configuration section in the last step, keep reading (if you didn’t- and most of you won’t- go ahead and skip to step 14). I strongly suggest committing those changes and testing the server again before removing test mode.  To do this, simply click “Change” at the very bottom of the configuration area and then click “Restart csf+lfd” on the next page that appears.  Then, test everything again and make sure everything works before going back into the configuration file to turn off test mode.

14. Okay, now let’s turn off testing mode.  At the very beginning of the csf configuration page, change the value of “TESTING” (should be the very first option) from ” 1 “  to  ” 0 ” (zero) and then scroll all the way to the bottom of the page and click “Change”.

15. A new page will appear stating that you should restart csf & lfd.  Easy enough, because there’s a button right under there called “Restart csf+lfd.” Go ahead and click it!

16. A bunch of iptables rules will fly by on the screen.  Don’t worry about those, csf is just showing you what it’s up to.  Go ahead and scroll to the bottom of the page and click “Return”.  You’ll be returned to csf’s main interface.  You’re just about done, but before you leave, take note of the second section of the interface called “Upgrade”.  If you ever see an “upgrade” button here, go ahead and click it to upgrade to the latest version of csf/lfd (you may already have an upgrade to perform, so check now).  Other than that, though, you’re now free to log out of SSH and WHM at this point, because you’re done!

Well, that’s it – you now have an awesome firewall and log monitoring program installed on your cPanel system.  One last note: keep in mind that you now have a living firewall installed on your system.  Whenever something goes amiss with your server (clients can’t connect, you can’t connect, bizarre system errors, etc.), your firewall should be one of the first places you should look for a misconfiguration.  To test to see if your firewall is causing the problem, csf has a handy button called “Disable Firewall” right on its main interface that will allow you to temporarily turn off the firewall.  If the error or problem goes away after disabling the firewall, it’s probably your csf configuration or lfd has the IP blocked.  You need to check your csf configuration and lfd’s block lists to see what is causing the system to falsely block your port or IP.   Once you’ve corrected it, there’s another button on the csf interface called “Firewall Restart” that will restart the firewall for you.

I hope you found this article useful.  Csf is an awesome product, and free, but the guys who made the product put a lot of effort and time into creating and maintaining this security must-have.  If you find csf useful, you should show them your appreciation with a small donation.  There are PayPal buttons for doing just that at the bottom of the main csf page on their website.

Tell us about your experiences installing and using csf/lfd in the comments below; is there another firewall product you’d recommend insead?  Let us know!

Posted in Installation & Configuration, Security & Safety, Server Health & Status | Leave a comment

Bad Behavior has blocked 7540 access attempts in the last 7 days.

Page optimized by WP Minify WordPress Plugin