How to Start and Enable Firewalld on CentOS 7

Reading Time: 1 minute
In this article, we discuss how to start and enable firewalld. It is highly recommended that you have a firewall protecting your server.
Pre-Flight Check
  • These instructions are intended specifically for enabling and starting Firewalld CentOS 7.
  • I’ll be working from a Liquid Web Self Managed CentOS 7 server, and I’ll be logged in as root.

Continue reading “How to Start and Enable Firewalld on CentOS 7”

Top 5 Reasons To Use CentOS 7

Reading Time: 4 minutes

When you’re considering which Operating System to use for web hosting, there are many options available to you. We’re going to discuss 5 reasons you should choose CentOS 7 and the strengths of the platform. CentOS has been the preferred Linux distribution in the hosting industry for many years, and it was only recently that this distro was overtaken by Ubuntu Server as the primary OS used for web hosting.

Continue reading “Top 5 Reasons To Use CentOS 7”

Using The One-Time Secret Tool In Manage

Reading Time: 2 minutes

In order for one of our clients to start using the ‘one time secret’ tool within manage, you will need to login to the Manage portal to get started. Typically, passwords are not meant to be shared. Unfortunately, sometimes you will need to share a password or other sensitive data with the support admin you are working with. Regrettably, trying to pass along individuals character over the phone can be frustrating, annoying, and overly time consuming, and more so when a password is long and if the phone has a bad connection.

So, what can we do when it is time to share a password with support? Using the One Time Secret tool in your Liquid Web account allows you and your Heroic Support admin to share a password in a safe and secure manner that will enable them access to your password or other sensitive data.

The One Time Secret tool is also useful when you need us to change a server’s root password for you or, we need a cpanel password to assist you with a support request.

Note:
The username and IP address of the secret submitter are kept in logs stored internally, as well as timestamps for submission, and retrieval or expiration.

So, how do we access and utilize this tool? Let’s jump right in…

  1. Log into your Liquid Web account.
  2. From the home page of your account, click on Account in the left side menu and then, one the “Secrets” tab.secrets tab
    Warning:
    One Time Secret is not available for HIPAA customers.
  3. This will open the One-Time Secret home page.
    one-time secret home page
  4. Click Create New One-Time Secret.create new button highlighted
  5. Enter the message or password you need to share with us. This will encrypt the message and store it in an internal database.secret created
  6. Click Submit One-Time Secret to save your password. Click the link below to view the secure one-time secret.

submit button highlighted

Both you and the admin can now view the password. Passwords are decrypted when the secret is viewed.

Caution:
Your secret is only viewable once before it is removed forever. Additionally, if the secret is not viewed within 24 hours, it is removed from the One Time Secret tool.

Have more questions about this tool? Reach out to one of our Heroic Support admins 24 hours a day, 365 days a year by creating a ticket at support@liquidweb.com, opening a chat with us or giving us a call at 1-800-580-4985. We are always looking forward to providing an answer to any questions you may have!

Thank you for hosting with Liquidweb!

How To Setup Let’s Encrypt on CentOS 7

Reading Time: 4 minutes

Securing Your Site

In this tutorial, we will be outlining a handy way of getting HTTPS enabled on all of your domains by using SSL’s to provide the first step in that process.

Domains secured with SSL’s are needed more often every day. If you don’t yet have an SSL on your site to encrypt your data passing over the net, you should reconsider this decision. Rather than showing an extra layer of security, modern browsers instead now display a warning when a website does not have an SSL.  This essentially requires sites to maintain a positive image by adding an SSL.

Let’s Encrypt has become a very popular solution for every sized business concerned with securing its connections to its website. To aid in implementing this, we recommend using Certbot. Certbot is a open source, free software tool for automatically installing and renewing SSLs certificates. Certbot implements these SSLs by working closely with Let’s Encrypt, the well known SSL provider, by creating the SSL’s for the server. Best news of all? Let’s Encrypt is completely free!

Continue reading “How To Setup Let’s Encrypt on CentOS 7”

Top Ten 2019 Password Security Standards

Reading Time: 4 minutes

 

Here are the top ten password security standards and specification for 2019. Use these tips to increase your overall security and remember, your server is only as secure as your weakest password or point of authentication.

Follow these top 10 best practices for 2019 to better protect all of your information.

Continue reading “Top Ten 2019 Password Security Standards”

Choosing An SSL Certificate

Reading Time: 5 minutes

Which one is right for you? 


You have invested your time and money and worked hard to build the perfect website that clearly reflects the amazing features of all of your products. You are finally ready to launch but, you also want to ensure that when your clients go to buy one of your products, their transactions are safe and secure. You may be thinking to yourself… 

Continue reading “Choosing An SSL Certificate”

How To Secure Your WordPress Site

Reading Time: 4 minutes

WordPress is one of the most popular Content Management Systems on the Internet. Due to it’s popularity, it is also the target of many hackers.  We’re here to show you our top 5 recommendations on how to secure your WordPress site based on issues we’ve come across.

1. Keep WordPress Up to Date!

Our number one and top recommendation is to keep WordPress up to date! WordPress is a very active platform and updates come out regularly for it. The updates include many new features and changes in the backend, but also patch many bugs and exploits that the WordPress team finds. Just take a look at the releases and patch notes on https://wordpress.org/news/ sometime to get an idea of how much work gets put into finding and fixing these problems!

Being even just one or two versions behind can leave your site open to hackers that analyze the updates, create exploits, and go looking for outdated sites across the Internet. The longer a site isn’t updated, the more exploits and vulnerabilities are out there, and the increased likelihood that your site could be compromised.

The same rule applies to your Plugins and Themes, make sure those are all properly updated for the same reasons! Which brings us to item two on our list!

2. Review your Plugins and Themes!

WordPress is great because the plugins can quickly and easily give new features and customize your site very quickly, and themes can give your site a very professional appearance in a matter of seconds, but if they are not properly maintained, it could lead to problems down the road.

First, just remove any plugins and themes you don’t need. You could leave them disabled, but outright removing them is a safer option as the files wouldn’t be sitting on your server. Even if it’s disabled, it could still potentially be reached if an exploit can gain access to the files.

A side effect of removing the plugins is that it could actually speed up our site as well!

After removing any plugins and themes you don’t need, make sure to keep the ones you have left updated. WordPress can generally check for updates right in the admin area, but if you bought a plugin from a third party source, make sure to check with them for any updates. It would also be recommended to visit the website of each plugin and theme or even check reviews on other sites to make sure development is still active on it and that there are no known vulnerabilities.

3. Protect your logins!

Having your site publicly accessible out on the internet means customers and potential clients can access your site, but so can bots and people with malicious intentions! By default WordPress allows you to go to yourdomain.com/wp-login.php or yourdomain.com/wp-admin and should bring up a login page. If you try that on any of your sites and you get the login page, it’s highly recommended you use a plugin to hide where you go to log in.

WordPress does have some general security that blocks attempts after a few failed attempts, but if thousands of bots are all trying to log in and guess passwords, why even give them the chance to try? Make sure you use strong passwords, don’t use the same username and passwords in multiple locations, and go through your WordPress users to make sure they are all still valid. For example, if you gave a developer access years ago, maybe you don’t need that user sitting around there still.

4. Install protection plugins

I know I said to reduce your plugins earlier, but I would recommend having some plugins to block malicious connections, monitor suspicious activity, and scan site files for malware. We recommend iThemes Security, as it offers a lot of different features in just a single plugin, but you can look up what’s popular and read other reviews to help you decide on what would be the best fit with your site. For example, if you have a site where users can upload data, it would be a good idea to scan those files as they are being uploaded and block or at least report any that trigger warnings in a plugin that scans for viruses and malware.

Depending on how much protection you need, paid options would be recommended over free options to help increase the chances that newer exploits are blocked as well with more features and newer virus definitions.

5. Make sure you have good backups

Having good backups isn’t exactly a proactive step on how to protect your site, but it sure is a reactive step that can greatly help if the need arises. It’s a good idea for any business that relies on the data on their site. Think about all the orders, profiles, records, logs, and any other important information stored on your site, then imagine if something causes a problem and the whole site gets deleted, maybe a hard drive crash or malicious code is injected into it somewhere and causes the data to be lost. If you have no backups at all to restore from, then depending on the nature of your business this may be hundreds of work hours for a team to rebuild the site, lost revenue, lost customers, and would definitely be a major hit to your site’s reputation.

If you did have backups, depending on the frequency of the backups and how quickly the problem was noticed and rolled back, there may be little to no data loss, customers may not notice, and the site can quickly bounce back.

We highly recommend having multiple backups taken over a period of time. The more backups you have the more options you would have to restore from. Having only one daily backup could cause problems if an issue isn’t noticed until three days after it happens. Active sites may need continuous backups compared to a static site that maybe hasn’t changed in months.

Also storing your backups in different locations would help spread out the number of available backup copies. Like if a dedicated backup hard drive failed then you could still have remote backups saved on a different service that wouldn’t be affected. Think of it like not putting all your eggs in one basket! For more information on good backup practices, see Best Practices: Developing a BackUp Plan.

Hopefully, you gained something useful from this article! If you or a friend are in the market for a web host, feel free to talk to a Liquid Web tech by phone or in a chat 24 hours a day! Thanks for reading!

How to Set Up Multiple SSLs on One IP With Nginx

Reading Time: 6 minutes

With the shortage of available address space in IPv4, IPs are becoming increasingly difficult to come by, and in some cases, increasingly expensive. However, in most instances, this is not a drawback. Servers are perfectly capable of hosting multiple websites on one IP address, as they have for years.

But, there was a time when using an SSL certificate to secure traffic to your site required having a separate IPv4 address for each secured domain. This is not because SSLs were bound to IPs, or even to servers, but because the request for SSL certificate information did not specify what domain was being loaded, and thus the server was forced to respond with only one certificate. A name mismatch caused an insecure certificate warning, and therefore, a server owner was required to have unique IPs for all SSL hosts.

Luckily, IPv4 limitations have brought new technologies and usability to the forefront, most notably, Server Name Indication (SNI).

 

Why Do I Need an SSL?

Secure Socket Layer (SSL) certificates allow two-way encrypted communication between a client and a server. This allows any data protection from prying eyes, including sensitive information like credit card numbers or passwords. SSLs are optionally signed by a well-known, third-party signing authority, such as GlobalSign. The most common use of such certificates are to secure web traffic over HTTPS.

When browsing an HTTPS site, rather than displaying a positive indicator, modern browsers show a negative indicator for a site that is not using an SSL. So, websites that don’t have an SSL will have a red flag right off the bat for any new visitors. Sites that want to maintain reputation are therefore forced to get an SSL.

Luckily, it is so easy to get and install an SSL, even for free, that this is reduced to a basic formality. We’ll cover the specifics of this below.

 

What is SNI?

Server Name Indication is a browser and web server capability in which an HTTPS request includes an extra header, server_name, to which the server can respond with the appropriate SSL certificate. This allows a single IP address to host hundreds or thousands of domains, each with their own SSL!

SNI technology is available on all modern browsers and web server software, so some 98+% of web users, according to W3, will be able to support it.

 

Pre-Flight Check

We’ll be working on a CentOS 7 server that uses Nginx and PHP-FPM to host websites without any control panel (cPanel, Plesk, etc.). This is commonly referred to as a “LEMP” stack, which substitutes Nginx for Apache in the “LAMP” stack. These instructions will be similar to most other flavors of Linux, though the installation of Let’s Encrypt for Ubuntu 18.04 will be different. I’ll include side-by-side instructions for both CentOS 7 and Ubuntu 18.04.

For the remainder of the instructions, we’ll assume you have Nginx installed and set up to host multiple websites, including firewall configuration to open necessary ports (80 and 443). We are connected over SSH to a shell on our server as root.

Note
If you have SSLs for each domain, but they are just not yet installed, you should use Step 3a to add them manually. If you do not have SSLs and would like to use the free Let’s Encrypt service to order and automatically configure them, you should use Step 3b.

 

Step 1: Enabling SNI in Nginx

Our first step is already complete! Modern repository versions of Nginx will be compiled with OpenSSL support to server SNI information by default. We can confirm this on the command line with:

nginx -V

This will output a bunch of text, but we are interested in just this line:

...
TLS SNI support enabled
...

If you do not have a line like this one, then Nginx will have to be re-compiled manually to include this support. This would be a very rare instance, such as in an outdated version of Nginx, one already manually compiled from source with a different OpenSSL library. The Nginx version installed by the CentOS 7 EPEL repository (1.12.2) and the one included with Ubuntu 18.04 (1.14.0) will support SNI.

Step 2: Configuring Nginx Virtual Hosts

Since you have already set up more than one domain in Nginx, you likely have server configuration blocks set up for each site in a separate file. Just in case you don’t, let’s first ensure that our domains are set up for non-SSL traffic. If they are, you can skip this step. We’ll be working on domain.com and example.com.

vim /etc/nginx/sites-available/domain.com

Note
If you don’t happen to have sites-enabled or sites-available folders, and you want to use them, you can create /etc/nginx/sites-available and /etc/nginx/sites-enabled with the mkdir command. Afterward,  inside /etc/nginx/nginx.conf, add this line anywhere inside the main http{} block (we recommend putting it right after the include line that talks about conf.d):

include /etc/nginx/sites-enabled/*;

Otherwise, you can make your configurations in /etc/nginx/conf.d/*.conf.

At the very least, insert the following options, replacing the document root with the real path to your site files, and adding any other variables you require for your sites:

server {
listen 80;
server_name domain.com;
root /var/www/domain.com;
...
}

A similar file should be set up for example.com, and any other domains you wish to host. Once these files are created, we can enable them with a symbolic link:

ln -s /etc/nginx/sites-available/domain.com /etc/nginx/sites-enabled/

ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

Now, we restart Nginx…

systemctl reload nginx

This reloads the configuration files without restarting the application. We can confirm that the two we just made are loaded using:

nginx -T

You should see your server_name line for both domain.com and example.com.

Note
The listen line included in the server block above will allow the site to listen on any IP that is on the server. If you would like to specify an IP instead, you can use the IP:port format instead, like this:

server {
listen 123.45.67.89:80;
...
}

Step 3a: Add Existing SSLs to Nginx Virtual Hosts

Now that we have valid running configurations, we can add the SSLs we have for these domains as new server blocks in Nginx. First, save your SSL certificate and the (private) key to a global folder on the server, with names that indicate the relevant domain. Let’s say that you chose the global folder of /etc/ssl/. Our names, in this case, will be /etc/ssl/domain.com.crt (which contains the certificate itself and any chain certificates from the signing authority), and /etc/ssl/domain.com.key, which contains the private key. Edit the configuration files we created:

vim /etc/nginx/sites-available/domain.com

Add a brand new server block underneath the end of the existing one (outside of the last curly brace) with the following information:

server {
listen 443;
server_name domain.com;
root /var/www/domain.com;
ssl_certificate /etc/ssl/domain.com.crt;
ssl_certificate_key /etc/ssl/domain.com.key;
...
}

Note the change of the listening port to 443 (for HTTPS) and the addition of the ssl_certificate and ssl_certificate_key lines. Instead of rewriting the whole block, you could copy the original server block and then add these extra lines, while changing the listen port. Save this file and reload the Nginx configuration.

systemctl reload nginx

We again confirm the change is in place using:

nginx -T

For some setups you’ll see two server_name lines each for domain.com and example.com, one using port 80 and one using port 443. If you do, you can skip to Step 4, otherwise continue to the next step.

Step 3b: Install and Configure Let’s Encrypt

Let’s next set up the free SSL provider Let’s Encrypt to automatically sign certificates for all of the domains we just set up in Nginx. On Ubuntu 18.04, add the PPA and install the certificate scripts with aptitude:

add-apt-repository ppa:certbot/certbot

apt-get update

apt-get install certbot python-certbot-nginx

In CentOS 7, we install the EPEL repository and install the certificate helper from there.

yum install epel-release

yum install certbot python2-certbot-nginx

On both systems, we can now read the Nginx configuration and ask the Certbot to assign us some certificates.

certbot --nginx

This will ask you some questions about which domains you would like to use (you can leave the option blank to select all domains) and whether you would like Nginx to redirect traffic to your new SSL (we would!). After it finishes it’s signing process, Nginx should automatically reload its configuration, but in case it doesn’t, reload it manually:

systemctl reload nginx

You can now check the running configuration with:

nginx -T

You should now instead see two server_name lines each for domain.com and example.com, one using port 80 and one using port 443.

Let’s Encrypt certificates are only valid for 90 days from issuance, so we want to ensure that they are automatically renewed. Edit the cron file for the root user by running:

crontab -e

The cron should look like this:

45 2 * * 3,6 certbot renew && systemctl reload nginx

Once you save this file, every Wednesday and Saturday at 2:45 AM, the certbot command will check for any needed renewals, automatically download and install the certs, followed by a reload of the Nginx configuration.

Step 4: Verify Installation and Validity

We should now check the validity of our SSLs and ensure that browsers see the certificates properly. Visit https://sslcheck.liquidweb.com/ and type in your domain names to check the site’s SSL on your server. You should see four green checkmarks, indicatating SSL protection.

We hope you’ve enjoyed our tutorial on how to install SSLs on multiple sites within one server. Liquid Web customers have access to our support team 24/7.  We can help with signed SSL or ordering a new server for an easy transfer over to Liquid Web.