Install vsftpd on Ubuntu 16.04

Installing vsftpd allows you to upload files to a server, the concept is comparable to that of Google Drive.  When you invite specified users to your Google Drive they can create, delete, upload and download files all behind a secure login. Vsftpd is excellent for company’s looking for an alternative to Google Drive or for anyone who wants to create a robust server. This “Very Secure File Transfer Protocol Daemon” is favored for its security and speed and we’ll be showing you how to install vsftpd on an Ubuntu 16.04 LTS server.

 

Pre-Flight Check

  • These instructions are intended specifically for installing vsftpd on Ubuntu 16.04.
  • You must be logged in via SSH as the root user to follow these directions.
Warning:
FTP data is insecure; traffic is not encrypted, and all transmissions are clear text, including usernames, passwords, commands, and data. Consider securing your FTP connection (FTPS).

Step 1: Updating Apt-Get

As a matter of best practices we update apt-get with the following command:

apt-get update

Step 2: Installing Vsftpd

One command allows us to install vsftpd very easily.

apt-get -y install vsftpd

Step 3: Configuring Vsftpd

We’ve installed vsftpd, and now we will edit some options that will help us to protect the FTP environment and enable the environment for utilization. Enter the configuration file using the text editor of your choice.

vim /etc/vsftpd.conf

Change the values in the config file to match the values below and lastly, save exit by typing

:wq

 

anonymous_enable=NO
local_enable=YES
write_enable=YES
chroot_local_user=YES
ascii_upload_enable=YES
ascii_download_enable=YES

 

Click Here for a Further Explaination on Each Directive
Anonymous_enable: Prohibit anonymous internet users access files from your FTP. Change anonymous_enable section to NO.

Local_enable: If you have created users you can allow these users to log in by changing the local_enable setting to YES.

Write_enabled: Enable users the ability to write the directory, allowing them to upload files. Uncomment by removing the # in from of write_enabled:

Chroot jail: You can “chroot jail” local users, restricting them to their home directories (/home/username) and prohibiting access to any other part of the server. Choosing this is optional but if you state YES follow the steps in Step 4 for removing write privileges and making their own directory for uploads. If you select NO, the user will have access to other directories.

Step 4: Editing Permissions for a User

If you have an existing or new user that is not able to connect, try removing write privileges to their directory:

chmod a-w /home/username

Step 5: Creating the User a Directory

Create a directory just for FTP, in this case, and we are name it files. Afterward, this user will be able to upload and create files within the files folder:

mkdir /home/username/files

Step 6: Accepting FTP Traffic to Ports

There are a few ways to open ports within a server, below is one way of opening port 20 and 21 for FTP users to connect.

Note
Directly passing iptable commands, like below, can break some firewalls. In whichever method you choose to edit your iptables ensure that port 20 and 21 are open.

iptables -I INPUT 1 -p tcp --dport=20 -j ACCEPT

iptables -I INPUT 1 -p tcp --dport=21 -j ACCEPT

Step 7: Restarting the Vsftpd Service

Restarting vsftpd enables changes to the file (step 3) to be recognized.

service vsftpd restart

Step 8: Verifying Vsftpd

Now for a little fun, let’s connect to our FTP to verify it is working.

ftp 79.212.205.191

Example Output:

ftp 79.212.205.191
Connected to 79.212.205.191.
220 Welcome to FTP!
Name (79.212.205.191:terminalusername):<enter your FTP user>

You’ll also be able to connect via an FTP client, like Filezilla, using the IP address of your hostname and leaving the port number blank.  Take it for a spin and try to upload a file or write a file. If you enabled the chroot jail option, the user should not be able to go to any other parent directory.

 

Malicious Activity Detector (MAD) for Windows

One of the simplest goals of server security is keeping administrator credentials private. There is no better way to achieve this than through strict firewall rules that only allows specific IPs to authenticate. However, there are some situations where it is necessary to open a login prompt to the broader Internet. In this case, the only thing barring anonymous internet users from unauthorized access is your password. The stronger your password, the better off you are, but even the most cryptic passwords can be guessed given enough tries.

Malicious Activity Detector (MAD) helps protect you in these instances. It functions by monitoring login attempts to several services, and if it detects malicious activity, it applies a temporary block on that IP. If more attempts come in, the block continues to last longer. This method is exceptionally effective in preventing a successful brute-force attack while limiting the number of system resources expended.

 

Installation of MAD

Depending on the configuration and age of your server, you may already have it installed. Check the installation status by looking for an item in your Start Menu shown below.

Installing Liquid Web's Malicious Activity Detector for Windows tightens security for you server.

The program path is C:\Program Files (x86)\Liquid Web\MAD\MADGUI.exe

You may also check if “MAD.exe” is running from your Task Manager. If you don’t see it there, please Contact Support so that we may get it up and running for you. Once running,  we can move on to the configuration.

 

Note:
MAD will be installed on all Windows servers by default in the future.

 

Configuring MAD

MAD’s default settings offer protection for the most vulnerable services, and extra configuration is not required. That said, you may find yourself wanting to change its behavior, and we’re happy to give you the tools you need.

Let’s start with the most common change you may want to make: whitelisting and blacklisting. Opening the MAD Configure utility will get you on the right page. From here, you only need to choose the radio button for the list you want to modify, enter the IP, and click the button. You can remove entries in either list by right-clicking. This page also allows you to start or restart the service, but you shouldn’t need to use those functions.

The List tab easily let's you add in blacklisted or whitelisted IPs.

The next page is where most options are located. All of the service scanners list three choices for each: Enabled/Disabled, BlockThreshold, and Retention.

Our Malicious Activity Detector allows you to adjust settings for maximum security.

Enabled/Disabled -You may want to disable scanners for services that you do not have installed, but it is generally recommended to leave all options enabled due to minimal performance cost.

BlockThreshold – This setting controls how many ‘strikes’ it takes to be blocked. These are set fairly high by default to avoid affecting legitimate users, but you may want to lower the threshold to increase MAD’s sensitivity.

Retention -This refers to the size of the window that MAD looks at to determine if a user has met the BlockThreshold in seconds. By default, this is set to 300 (five minutes).

Example:
Set your BlockThreshold to 10 and your Retention to 300. If 9 failed attempts occurred at 12:00 and a failed attempt occurs before 12:05 it will be blocked. By 12:06 you will be in a new period and will be able to attempt 9 more times before being blocked.

PermaBlock – Sometimes robots can’t take the hint after being temporarily blocked several times in a row. The PermaBlock list remedies this situation. By default the retention period is 2 hours, this scanner checks for IPs that have been temp blocked five times (or your custom BlockThreshold). If it gets a hit, it does as the name implies and adds it to your blacklist, where it is managed much like manual entries.

AuditPolicy – This setting determines if MAD is allowed to edit your login event auditing policy. Disabling AuditPolicy is not recommended and may prevent MAD from working as intended.

TempBlockTimeout -When a block is triggered on one of the scanners the offending IP address will be blocked for this amount of time. Measured in seconds with a default setting of 900 (15 minutes).

 

Reviewing MAD Logs

MAD creates logs of all of the actions that it takes. It is good practice to review them regularly to see what has been going on. For example, if a certain service seems to be getting attacked more often than others you may want to consider hardening your firewall rules or MAD’s configuration itself.

Our Malicious Activity Detector keeps logs of anyone attempting to connect to your Windows server.

MAD also creates events in Windows Event Viewer under the ‘Applications and Services Logs’ folder. These events are most helpful for long-term investigation, as the folder will hold historical data for quite some time.

MAD also creates Events for long-term investigation, as the folder will hold historical data.

MAD for Windows is an excellent tool in your security arsenal, but a proactive plan is always better than a reactive one. We recommend utilizing Windows Firewall to ensure that only things that must be publicly accessible are. For further reading on security visit some of our other articles:

Security for Remote Desktop
Best Practices for Your Firewall

Install TeamViewer on Ubuntu 16.04 LTS

VNC (Virtual Network Computing) is a method for sharing a remote desktop environment. Allowing you to remote control another computer or server over the Internet or local network as if you were sitting in front of it. Keyboard and mouse strokes from your computer are relayed to the remote computer/server. There are many different kinds of VNC softwares available today. Several are cross-platform and add additional features, such as chat or file transfers. VNC is often used for remote technical support and remotely accessing files.

Have you ever wanted to open a file manager and browse your server’s files? Have you ever wanted to open a browser on your server and use it as a VPN? TeamViewer will allow you to do that without much effort. Once TeamViewer is set up on your server, accessing your server takes only a couple of clicks. Many additional features such as chat, file transfers, and wake-on-LAN are available through TeamViewer. They also offer monitoring, asset tracking, anti-malware, and backups for an additional fee.

TeamViewer supports text-based consoles as well as a GUI (Graphic User Interface). If you want to use TeamViewer without using a GUI you can skip installing a desktop environment and window session manager and go straight to the Installing TeamViewer section. However, for this guide, we will assume that remote control of a desktop environment is needed or otherwise wanted.

Prerequisites

You will need to have a server running Ubuntu 16.04 LTS with a desktop environment and a window session manager. There are many different types of desktop environments and window session managers you could install. There is plenty of debate in the Linux community, but for this guide, we recommend going with something lightweight. For that we suggest Xfce.  Another good option is LXDE which is again known for being lightweight and used in many different operating systems as the default desktop environment. Gnome, Mate, and KDE are also noteworthy. Like desktop environments, there are many window session managers and some even come with the desktop environment! We recommend using LightDM with Xfce. LightDM is easy to install and configure and is also very lightweight. You’ll need a TeamViewer account with your login credentials handy, along with the TeamViewer client installed on your local computer, or you can use the web client which requires Flash.

Once you have your Ubuntu 16.04 LTS server up and running, install the desktop environment and window session manager. For our build, we’ve installed Xfce with our Knowledge Base article. Next, install LightDM by running:
sudo apt install lightdmOnce installed you will need to configure it to use Xfce. You can do that by creating a file called /etc/lightdm/lightdm.conf using your favorite text editor and adding the following configuration settings:
sudo vim /etc/lightdm/lightdm.conf
[SeatDefaults] allow-guest=false
user-session=xfce

 

TeamViewer prefers connections using UDP and TCP on port 5938, but if that port is not available, it falls back to ports 80 (HTTP) or 443 (SSL). Port 80 is used only as a last resort and is not recommended due to the additional overhead.  Making connections over this port results in a laggy experience. If you are running firewalld use these commands to open port 5938:
sudo firewall-cmd --zone=public --add-port=5938/tcp
sudo firewall-cmd --zone=public --add-port=5938/udp
If you are using ConfigServer Security & Firewall (CSF) you will need to edit the configuration file. Open the file with your favorite text editor and add the port number to the lines that start with TCP_IN and UDP_IN. Remember to separate your port numbers with commas and then restart the firewall.
sudo vim /etc/csf/csf.conf
sudo csf -r

TeamViewer communicates on port 5938, if you use ConfigServer Security & Firewall (CSF) its necessary to add this port to the configuration file.

The firewall ports are open now that you’ve installed the desktop environment and window session manager. You can now reboot the server. Upon boot, the server will startup Xfce and LightDM.
shutdown -r now

 

To install TeamViewer, you first need to download the package:
wget https://download.teamviewer.com/download/linux/teamviewer-host_amd64.debThen use apt to install the package:
sudo apt install ./teamviewer-host_amd64.deb
During installation, TeamViewer adds the file /etc/apt/sources.list.d/teamviewer.list (DEB), which contains information about the repository. Apt update & upgrade allows you to keep the software up-to-date by simply running:
sudo apt update
sudo apt upgrade
Once TeamViewer is installed you will need to configure it for first time use.
sudo teamviewer setup

TeamViewer will prompt you to accept the license agreement and then ask you for your username and password for your TeamViewer account. The first time that you login TeamViewer will most likely send you an email to verify that you are trying to login to your account from a new location (i.e., your server). Until verified through email it will not allow you to log in until you confirm the new location. Check your inbox and spam folder for their email and click the link to approve the new login location. Afterward, go back to your server and re-enter the username and password to log in.

TeamViewer asks if you would like to add the server to “My computers” on your account. If you get a connection error make sure your server is connected to the Internet and that the proper ports are open in the firewall. Run:

sudo teamviewer setup

If everything goes as planned you should see something like this:The TeamViewer setup screen with ask for your email and password, necessary for future logins.

Now that TeamViewer is installed you can now connect to your server remotely with your TeamViewer client or by logging in with your account to https://login.teamviewer.com/LogOn. You will now see your server listed under “My computers” in TeamViewer. Just double-click on your server under “My computers” and it will connect to your Ubuntu server. Here is an example TeamViewer connected to my Ubuntu 16.04 LTS running Xfce and LightDM:An example TeamViewer connected to my Ubuntu 16.04 LTS running Xfce and LightDM.

You now know how to setup TeamViewer on Ubuntu server 16.04 LTS! If you are already a Liquid Web customer, feel free to contact The Most Helpful Humans™ with questions you may have in setting up a TeamViewer on Ubuntu 16.04 LTS.  We also have some more useful articles about Ubuntu.

Cloud Spectator is an independent, third-party cloud analytics confirms Liquid Web’s VPS servers outperform Rackspace, Amazon, and Digital Ocean across the board.

 

 

Improving Security for your Remote Desktop Connection

Remote Desktop Protocol (RDP) is the easiest and most common method for managing a Windows server. Included in all versions of Windows server and has a built-in client on all Windows desktops. There are also free applications available for Macintosh and Linux based desktops. Unfortunately, because it is so widely used, RDP is also the target of a large number of brute force attacks on the server. Malicious users will use compromised computers to attempt to connect to your server using RDP. Even if the attack is unsuccessful in guessing your administrator password, just the flood of attempted connections can cause instability and other performance issues on your server. Fortunately, there are some approaches you can use to minimize your exposure to these types of attacks.

Using a Virtual Private Network (or VPN) is one of the best ways to protect your server from malicious attacks over RDP. Using a VPN connection means that before attempting to reach your server, a connection must first be made to the secure private network. This private network is encrypted and hosted outside of your server, so the secure connection itself does not require any of your server’s resources. Once connected to the private network, your workstation is assigned a private IP address that is then used to open the RDP connection to the server. When using a VPN, the server is configured only to allow connections from the VPN address, rejecting any attempts from outside IP addresses (see Scoping Ports in Windows Firewall). The VPN not only protects the server from malicious connections, but it also protects the data transmitted between your local workstation and the server over the VPN connection. For more information, see our article What is a VPN Tunnel?

Note
All Liquid Web accounts come with one free Cloud VPN user. For a small monthly fee, you can add additional users. See our Hosting Advisors if you have any questions about our Cloud VPN service.

Like using a VPN, adding a hardware firewall to your server infrastructure further protects your server from malicious attacks. You can add a Liquid Web firewall to your account to allow only RDP connection from a trusted location. Our firewalls operate in much the same way that the software Windows firewall operates, but the functions are handled on the hardware itself, keeping your server resources free to handle legitimate requests. To learn more about adding a hardware firewall to your account, contact our Solutions team. If you already have a Liquid Web firewall in place, our Support team can verify that it is correctly configured to protect RDP connections.

Similar to using a VPN, you can use your Windows firewall to limit access to your RDP port (by default, port 3389). The process of restricting access to a port to a single IP address or group of IP addresses is known as “scoping” the port. When you scope the RDP port, your server will no longer accept connection attempts from any IP address not included in the scope. Scoping frees up server resources because the server doesn’t need to process malicious connection attempts, the rejected unauthorized user is denied at the firewall before ever reaching the RDP system. Here are the steps necessary to scope your RDP port:

  1. Log in to the server, click on the Windows icon, and type Windows Firewall into the search bar.
    Windows Firewall Search
  2. Click on Windows Firewall with Advanced Security.
  3. Click on Inbound Rules
    Inbound Firewall Rules section
  4. Scroll down to find a rule labeled RDP (or using port 3389).
  5. Double-click on the rule, then click the Scope tab.
    RDP Scope
  6. Make sure to include your current IP address in the list of allowed Remote IPs (you can find your current public IP address by going to http://ip.liquidweb.com.
  7. Click on the radio button for These IP Addresses: under Remote IP addresses.
  8. Click OK to save the changes.

While scoping the RDP port is a great way to protect your server from malicious attempts using the Remote Desktop Protocol, sometimes it is not possible to scope the port. For instance, if you or your developer must use a dynamic IP address connection, it may not be practical to limit access based on IP address. However, there are still steps you can take to improve performance and security for RDP connections.

Most brute force attacks on RDP use the default port of 3389. If there are numerous failed attempts to log in via RDP, you can change the port that RDP uses for connections.

  1. Before changing the RDP port, make sure the new port you want to use is open in the firewall to prevent being locked out of your server. The best way to do this is duplicate the current firewall rule for RDP, then update the new rule with the new port number you want to use.
  2. Login to your server and open the Registry editor by entering regedit.exe in the search bar.
  3. Once in the registry navigate to the following: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
  4. Once there scroll down the list till you find “PortNumber”
  5. Double-clicking on this will bring up the editor box.
  6. Change it from HEX to DEC so it’s in numbers.
  7. Set the port number here and hit OK (you can use whatever port number you wish, but you should pick a port that already isn’t in use for another service. A list of commonly used port numbers can be found on MIT’s website.)
  8. Close the registry editor and reboot the server.
  9. Be sure to reconnect to the server with the new RDP port number.

 

Remote Desktop Troubleshooting

Remote Desktop Protocol (or RDP) is the most common method of gaining administrative access to a Windows server. RDP is available on all versions of Windows server and a client (called Remote Desktop Connection) is included with all versions of Windows desktop operating systems. Clients are also available for Macintosh operating systems from Microsoft in the iTunes store and for Linux desktops with applications like FreeRDP. Connecting to your server via RDP allows you full control of the server desktop environment, just as if you were sitting in front of the server’s monitor and keyboard. Depending on your permissions and settings, you can copy and delete files, change file permissions or settings, and even print documents from the server.

Pre-Flight Check

Using Remote Desktop Protocol to manage a Windows server generally requires a few basic settings and information about the server.

  • First, the Remote Desktop Service must be running on the server to which you would like to connect (RDP uses port 3389 by default).
  • Second, you need to know the IP address of the server.  
  • Third, you must have a username and password that is allowed to connect to the server remotely (often, this is the primary administrator account, but can also be a secondary account set up specifically for remote access purposes).
  • Finally, the Windows firewall (and any other hardware or software firewalls) needs to be configured to allow Remote Connections from your location.

 

Once you have all of the correct settings enabled, IP address and user account details, you can connect RDP to your server! Just launch the RDP client, enter the IP address of the server and the user credentials, and log in to the server using what looks like the standard Windows desktop environment.

Image of Remote Desktop Connection

As helpful as the Remote Desktop Protocol can be when it comes to managing your Windows server, there are also times when the connection fails, which can be very frustrating as the error message is generally not very helpful (often just the window shown below).         

RDP Connection Error Pop Up

 

The error shown above means that for some reason, your client was unable to make a connection to the Windows server via the Remote Desktop Protocol. When you are experiencing connectivity issues, there are many items that you can check to try to resolve the problem.

 

  1. Ensure you can reach the server via ICMP (or Ping). Most desktop operating systems will allow you to send small bits of information to the computer to verify connectivity and connection speeds. Generally, you just need to open a terminal window (on a Windows desktop, press the Window key, then type cmd and press enter) and enter the following command: ping IP or ping domain.tld. Normally, you’ll receive an output that is similar:Ping Results
  2. This output shows the pings were successful to the destination and took between 50 ms and 150 ms to complete. These pings indicate a successful connection to the server as desired (at least over ICMP). If the output for the command shows a failure to respond, we know there is some network interference.
  3. If the ping test fails (indicated by repeating asterisks), check your internet connectivity to guarantee that you can reach other resources on the internet. If not, you may need to contact your local service provider to restore your internet access.
  4. Reaching other internet sites but not your server indicates your server is refusing connections from your IP address (due to security software or firewall settings). You may need to contact your hosting company to verify there is not an IP address blocked by your server. You can find your current public IP address by going to http://ip.liquidweb.com.
  5. Can you ping your server, but still can’t connect over RDP? It is likely an issue with the RDP service or your firewall. You’ll need to contact your hosting company to get assistance with the service or firewall.

Firewall Issues

Best practices in configuring a firewall is to allow the least amount of access necessary for the various connections to the server. Limiting the connections to a particular service like RDP is called “scoping” the access for that service. If your configured Windows firewall scopes traffic on RDP, it’s possible that a user may not be able to connect due to their IP address not being included in the rule. Access to the server via RDP from one user but another user is not, check the firewall; their IP address may not be included in the allowed list of IPs for Remote Desktop Access.

  1. Log in to the server, click on the Windows icon, and type Windows Firewall into the search bar.Firewall Settings
  2. Click on Windows Firewall with Advanced Security.
  3. Click on Inbound Rules
  4. Scroll down to find a rule labeled RDP (or using port 3389).
  5. Double-click on the rule, then click the Scope tab.Scope Tab
  6. Make sure the user’s current IP address is included in the list of allowed Remote IPs.

If you are unable to connect to the server from your location, contact your hosting company for help in checking the firewall rule for RDP access.

User Connectivity Problems

Can you connect to RDP using the administrator account, but one or more of the other accounts cannot? There may be a problem with the user account permissions.

  1. Make certain the user is a member of the Remote Desktop Users group. Log in to the server with the administrator account, then go to the Local Users and Groups control panel (Open Administrative Tools, then open Computer Management).Local Users and Groups
  2. Navigate to the Remote Desktop Users group and verify that the user is a member of the group. If they are not a member of the group, add them as a member of the group.
    remote desktop users group
  3. Go to the username under the Users tab. Make sure that the user account is not locked out. Accounts can get locked out due to too many attempts to log in with an incorrect password (either by the user or by a brute force attack on the server).
    account lockout screen
  4. Double check the firewall for the IP address of the user and add to the scope of the RDP rule.

No Available Connections/Sessions

By default, Windows server only allows two users to connect via RDP simultaneously. If both sessions are already in use, you will receive an error indicating that no additional users are allowed to connect at this time. Too Many Users Error

To resolve this issue, you will need to wait until one of the other users logs out or you’ll require to purchase additional RDP user licenses from your hosting provider (assuming that you regularly need access for more than two users at a time).

Failed login attempts during a brute force attack can sometimes take up RDP licenses, even though the session isn’t connecting. If you are experiencing unavailable sessions even when no one is logged in to the server, it’s possibly the result of a malicious login. The best remedy for this situation is to scope the firewall rule to prevent access attempts from unauthorized IP addresses.

Data Encryption Errors

If you are using an out of date Remote Desktop Client or are connecting to an older Windows server, you may receive an error that there is a problem with the TLS settings for the connection. Generally, you can resolve this issue by updating your RDP client software on your workstation. It may also be possible to set the client to ignore these errors, but that could leave your workstation and your server vulnerable to malicious attacks.

Sudden Disconnection

If you are using RDP and suddenly lose the connection, the issue is almost always related to your internet connection. Check to make sure that you can stay connected to other services (like running a ping command in the background). If you are not losing internet connectivity, it’s possible that the server is running out of memory or the RDP service may be experiencing an active attacked in a brute force attack. If you’ve confirmed that your internet connection is stable, contact your hosting company to make sure that the server is not the cause of the lost connection.

Slow Connection Issues

If the connection between your location and your server is slow your Remote Desktop Session may not function as smoothly as you would like. However, you may be able to adjust the Desktop Environment settings of the connection before you connect to simplify and speed up the connection.

  1. Open the Remote Desktop Client application (these directions are for the Windows built-in client, but most RDP clients have similar settings available).
  2. Click on the Experience tab to see the various items you can choose to enable or disable to improve your connection speeds. Change the drop-down to select a specific connection speed or select/deselect the various items to optimize performance.Remote Desktop Connection Settings

         

Windows 10 Update Issues

Oddly enough, Microsoft updates often cause problems with RDP connectivity. As recent as April 2018, an update on both the server operating system and the Windows 10 desktop operating system caused connectivity issues for many users. Generally, the best policy is to update both the server and workstation, as connectivity issues most often arise when the two systems are not on the same update cycle. You may be able to resolve a new connectivity issue by removing a recent Windows update (either on the server or the desktop). Many users also reported that disabling the Printer option from the local resources setting resolved the most recent connectivity issue.         

Local Resources

 

While RDP is a great tool for managing your Windows server, connectivity issues can be frustrating. By working through the possible causes of the connection problem, you will generally be able to get reconnected and working again in no time!

Getting Started with Ubuntu 16.04 LTS

A few configuration changes are needed as part of the basic setup with a new Ubuntu 16.04 LTS server. This article will provide a comprehensive list of those basic configurations and help to improve the security and usability of your server while creating a solid foundation to build on.

Root Login

First, we need to get logged into the server. To log in, you will need the Ubuntu server’s public IP address and the password for the “root” user account. If you are new to server administration, you may want to check out our SSH tutorial.
Start by logging in as the root user with the command below (be sure to enter your server’s public IP address):
ssh root@server_ipEnter the root password mentioned earlier and hit “Enter.” You may be prompted to change the root password upon first logging in.

 

Root User

The root user is the default administrative user within a Linux(Ubuntu) environment that has extensive privileges. Regular use of the root user account is discouraged as part of the power inherent within the root account is its ability to make very adverse changes. The control of this user can lead to many different issues, even if those changes made are by accident.
The solution is to set up an alternative user account with reduced privileges and make it a “superuser.”

 

Create a New User

Once you are logged in as root, we need to add a new user account to the server. Use the below example to create a new user on the server. Replace “test1” with a username that you like:

adduser test1

You will be asked a few questions, starting with the account password.
Be sure to enter a strong password and fill in any of the additional information. This information is optional, and you can just hit ENTER in any field you wish to skip.

 

Root Privileges

We should now have a new user account with regular account privileges. That said, there may be a time when we need to perform administrative level tasks.
Rather than continuously switching back and forth with the root account, we can set up what is called a “superuser” or root privileges for a regular account. Granting a regular user administrative rights will allow this user to run commands with administrative(root) privileges by putting the word “sudo” before each command.
To give these privileges to the new user, we need to add the new user to the sudo group. On Ubuntu 16.04, users that belong to the sudo group are allowed to use the sudo command by default.
While logged in as root, run the below command to add the newly created user to the sudo group:

usermod -aG sudo test1

That user can now run commands with superuser privileges using the sudo command!

 

Public Key Authentication

Next, we recommend that you set up public key authentication for the new user. Setting up a public key will configure the server to require a private SSH key when you try to log in, adding another layer of security to the server. To setup Public Key Authentication, please follow the steps outlined in our “Using-SSH-Keys” article.

 

Disable Password Authentication

Following the steps outlined in the previously mentioned “Using-SSH-Keys” article, results in the new user ability to use the SSH key to log in. Once you have confirmed the SSH Key is working, we can proceed with disabling password-only authentication to increase the server’s security even further. Doing so will restrict SSH access to your server to public key authentication only, reducing entry to your Ubuntu server via the keys installed on your computer.

Note
You should only disable password authentication if you successfully installed and tested the public key as recommended. Otherwise, you have the potential of being locked out of your server.

To disable password authentication on the server, start with the sshd configuration file. Log into the server as root and make a backup of the sshd_config file:

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Now open the SSH daemon configuration using nano:

nano /etc/ssh/sshd_config

Find the line for “PasswordAuthentication” and delete the preceding “#” to uncomment the line. Change its value from “yes” to “no” so that it looks like this:

PasswordAuthentication no

The below settings are important for key-only authentication and set by default. Be sure to double check to configure as shown:

PubkeyAuthentication yes
ChallengeResponseAuthentication no

Once done, save and close the file with CTRL-X, then Y, then ENTER.

We need to reload/restart the SSH daemon to recognize the changes with the below command:

systemctl reload sshd

Password authentication is now disabled, and access restricted to SSH key authentication.

Set Up a Basic Firewall

The default firewall management on Ubuntu is iptables. Iptables offers powerful functionality. However, it has a complex syntax that can be confusing for a lot of users. A more user-friendly language can make managing your firewall much easier.
Enter Uncomplicated Firewall (UFW); the recommended alternative to iptables for managing firewall rules on Ubuntu 16.04. Most standard Ubuntu installations are built with UFW by default. A few simple commands can install where UFW is not present.

 

Install UFW

Before performing any new install, it is always best practice to run a package update; you’ll need root SSH access to the server. Updating helps to ensure that the latest version of the software package. Use the below commands to update the server packages and then we can proceed with the UFW install:

apt update

apt upgrade

With the packages updates, it’s time for us to install UFW:
apt install ufwOnce the above command completes, you can confirm the UFW install with a simple version command:
ufw --version

UFW is essentially a wrapper for iptables and netfilters, so there is no need to enable or restart the service with systemd. Though UFW is installed, it is not “ON” by default. The firewall still needs to be enabled with the below command:

ufw enable

Note
Recreating any pre-existing iptables rules is necessary for UFW. It is best to set up the basic firewall rules then enable UFW to ensure you are not accidentally locked out while working via SSH.

 

Using UFW

UFW is easy to learn! Various programs can provide support for UFW in the form of app profiles which are pretty straightforward. Using the app profiles, you can allow or deny access for specific applications. Below are a few examples of how to view and manage these profiles:

  • List all the profiles provided by currently installed packages:

ufw app list

Available applications:
Apache
Apache Full
Apache Secure
OpenSSH

  • Allow “full” access to Apache on port 80 and 443:

ufw allow "Apache Full"

Rule added
Rule added (v6)

  • Allow SSH access:

ufw allow "OpenSSH"

Rule added
Rule added (v6)

  • View the detailed status of UFW:

ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action From
--                         ------ ----
22/tcp (OpenSSH)           ALLOW IN Anywhere           
22/tcp (OpenSSH (v6))      ALLOW IN Anywhere (v6)

As you can see, the App profiles feature in UFW makes it easy to manage services in your firewall. Newer servers will not have many profiles to start with. As you continue to install more applications, any that support UFW are included in the list of profiles shown when you run the ufw app list command.

If you have completed all of the configurations outlined above, you now have a solid foundation to start installing any other software you need on your new Ubuntu 16.04 server.

 

Whitelisting in ModSecurity

Broken down into two parts our article’s first section hits on “how to whitelist IPs or URIs,” for people who are somewhat familiar with ModSecurity but want to know further about the process. Our second section examines why we configure ModSecurity and how to prevent the security of the server from getting in the way of our work. If you have a Fully Managed Liquid Web server reach out to our Heroic Support team for assistance with whitelisting!

How to Whitelist IPs or URIs

“ModSecurity is a toolkit for real-time web application monitoring, logging, and access control.” (modsecurity.org).  In simple terms, this means that ModSec, also called mod_security or ModSecurity, is a web application firewall that can actively look for attacks to the system and stop malicious activity. However, sometimes these rules trigger when legitimate work is taking place, blocking your IP and stopping you or your developer’s until you can remove the IP block. The way around for being blocked is known as whitelisting, which essentially allows for a specific IP to access the server.   There are a few ways to whitelist a request in ModSec, either by IP or by URI (URIs are specific pages on the website). 

Getting Started

  1. Find your IP or ask your developer for theirs. (You can find this by going to ip.liquidweb.com)If you or your developer have a static IP (one that will not change), one way you can whitelist the ModSec rules is by IP.
  2. Find the ModSec error in the Apache error logs with the following command (Be sure to modify the command with your IP in place of “IP here.”):
    grep ModSec /usr/local/apache/logs/error_log | grep “IP here”.
  3. The output of this command will give you a list of hits for ModSecurity from you or your developer’s IP, which you can see below. While this looks intimidating, you will only want to pay attention to 3 bits of information highlighted.  Please note, the output will not show these colors when you are viewing the files.
Note
Blue = client, the IP which tripped the rule
Red
= ID number of tripped rule within ModSec
Green = URI, the location where the error started from

[Fri May 25 23:07:04.178701 2018] [:error] [pid 78007:tid 139708457686784] [client 61.14.210.4:30095] [client 61.14.210.4] ModSecurity: Access denied with code 406 (phase 2). Pattern match "Mozilla/(4|5)\\\\.0$" at REQUEST_HEADERS:User-Agent. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "109"] [id "20000221"] [hostname "67.227.209.163"] [uri "/db/index.php"] [unique_id "WwjPWChxvG1CO4kz-D55eQAAACU"]

 

Whitelist By IP:

1. Once you have the correct ModSec error, you will need to edit the ModSec configuration. If you are using Easy Apache 4 you will find the configuration file with this path:
/etc/apache2/conf.d/modsec2/whitelist.conf

2. Open the file with your favorite text editor, such as vim, nano, or file manager like so:

vim /etc/apache2/conf.d/whitelist.conf

3.  The blue text above will be the IP address that you are whitelisting from the original error. You must keep the backslashes (\) and up-carrot (^) in order for the IP to be read correctly. Thus it will always look something like:

“^192\.168\.896\.321”

For for the id, noted in red, you will change the number after the colon, which will be the Apache error log like we saw above. This will look similar to:

Id:2000221

Add the following code with the colored sections edited to match your intended IP.

SecRule REMOTE_ADDR "^64\.14\.210\.4"
"phase:1,nolog,allow,ctl:ruleEngine=off,id:20000221"

 

Whitelist By URI:

If your IP is dynamic (changing) and you keep getting blocked in the firewall, it is best to whitelist it via URI, the yellow item in the ModSec error.

1. Begin by opening the Easy Apache 4 configuration file:

vim /etc/apache2/conf.d/whitelist.conf

2. Add the following text to the configuration. Remember to pay attention to the highlighted parts.  Change the yellow “/db/index.php” to match your URI and the red id to match the id of your error (Do not use the colon in this one).

<LocationMatch "/db/index.php">
SecRuleRemoveById 20000221
</LocationMatch>

3. The final step for whitelisting, before you finalize the process, is to ensure you have correctly set up the whitelist. For Easy Apache 4 you will run the command:
apachectl -t

As long as the command returns “Syntax Ok” you are safe to make the whitelist active by restarting Apache. Otherwise, review the whitelists to make sure the syntax matches up correctly with the above directions.

4. Lastly, restart Apache with the following command.

/scripts/restartsrv_httpd

You have successfully whitelisted yourself in ModSec!

 

Using ModSec

Cyber Security is a hydra; once one threat is cut off, two more grow back. While this is not a new analogy, it’s important to understand as we battle threats to our network, computers, and servers. With all the complexities that come with security, I want to talk about adequately configuring ModSec to deter threats while still allowing you to work on your websites. Often, when it comes to server security, too much protection can hinder effectiveness.

For example, say you have the following set up on your server:

  • You do not allow root SSH login to the server
  • utilize dual-factor authentication for any SSH logins
  • use an SSH key for the sudo user and require other security safeguards

While this type of configuration is secure, it takes longer to log into your system to make a quick edit to your settings, a double-edged sword; how can you keep the server safe while not tying your own hands?  A great example of how this plays out is using ModSec.

ModSec can block your IP if it falsely flags your work. While this module improves system security, you’ll need to be aware of properly implementing and “scoping” the technology. Scoping in this sense means to manage risks, the focus of what is important for security while still allowing work on the server with minimal interference. To tune out legitimate requests to your server, such as when you are editing your website’s code via a plugin, ModSec has the options to whitelist rules or IPs and keep your work on track.

Whitelisting an IP from the rules that ModSec follows is a great option so long as the IP never changes (i.e. a static IP, see article here to learn more https://support.google.com/fiber/answer/3547208?hl=en) and is limited to only people you trust. This method prevents ModSec from viewing your requests as malicious and blocking your IP. This practice has the drawback that if someone (say an unhappy employee) has access to your network, they now have a way around ModSec to attack your server.

With non-static (dynamic) IPs the problems of whitelisting an IP are readily apparent. With the continual change of a dynamic IP, it creates the potential of exploiting your server, as someone could use an old IP to access the server. Whitelisting specific rules comes to save the day! When you whitelist by rules, you can edit with granularity and limit the rules to particular domains and URIs, protecting the rest of the server from attacks related to that same rule!

Example of ModSecurity

ModSec reads a series of rules and applies them to incoming requests being made to the web server. An example of what a block looks like is:

[Sat Jun 30 02:21:56.013837 2018] [:error] [pid 79577:tid 139862413879040] [client 120.27.217.223:24397] [client 120.27.217.223] ModSecurity: Access denied with code 406 (phase 2). Pattern match "Mozilla/(4|5)\\\\.0$" at REQUEST_HEADERS:User-Agent. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "109"] [id "2000064"] [hostname "67.227.192.139"] [uri "/mysql/index.php"] [unique_id "WzchhAjuZ6wPAzo9AwW1WwAAAE8"]

This error shows Apache stopped a potential attack on a file at /mysql/index.php. This is an error similar to what appears when the code is being written or edited within programs like Drupal or WordPress.

Evaluating ModSecurity

If you are persistently being blocked in your firewall while working on your code, ModSec is the likely culprit. The ModSec errors can be found in the Apache error log (in cPanel the path is /usr/local/apache/logs/error_log). The phrase “ModSec” can be quickly isolated from the log (via the command ‘grep “ModSec” /usr/local/apache/logs/error_log’). By comparing you or your developer(s) IP to the log, you’ll be able to identify stopped requests that are legitimate. Verify these are valid requests by double-checking that someone in your organization made them. Once you have done so, you can move forward in setting up a whitelist for the error, per the steps above.

Again, we want to scope to allow the least amount of wiggle room for an attack and ensure we can keep working. If you are unable to have a trusted static IP, you’ll need to use the whitelist URI  method, providing the specific page as an exemption. Once completed, remove both whitelisted items from the configuration file, in case of a genuine attack.

On a parting note, I encourage you to explore ModSec and learn more of the ins and outs of the software. Exploring different methods of whitelisting can be a lot of for to learn and most importantly helps to tighten server security. As always, our Fully Supported Customers can contact our Helpful Human Support team for assistance. Check out articles on security in our Knowledge Base, like this one on Maldet! It’s another excellent way to learn about your server and develop an understanding of server security.

Best Practices for Firewall Rules

Basic Firewall Rules

In a firewall rule, the action component decides if it will permit or block traffic. It has an action on match feature. For example, if the traffic matches the components of a rule, then it will be permitted to connect to the network. It is essential to consider the potential security risks when modifying a firewall rule to avoid future issues. Following best practices for configuring firewalls can help you maximize the effectiveness of your solution.

Continue reading “Best Practices for Firewall Rules”

An Introduction to Firewalls

In network security, the first line of defense that should be used is a firewall. What is a firewall? It is a protective layer for your server that monitors and limits the incoming and outgoing network traffic. It uses a set of rules to determine to allow or block specific network traffic. Firewalls can prevent unauthorized use before reaching your servers. Firewalls can be hardware or software based.

Continue reading “An Introduction to Firewalls”