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 an attempted attack reaches your server, they will first connect to a 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.

 

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.

Difference Between ipv4 and ipv6

The Internet Protocol (IP) system designates how networked devices can address one another across the internet. The first major version of IP, IPv4, was deployed to the public ARPANET in 1983. IPv4 uses 4 one byte segments to designate a devices address, this 32-bit address space allows for 232 addresses to be used in total. The next major iteration of IP is called IPv6 and it uses a 128-bit address space allowing for significantly more IP addresses to be assigned. Continue reading “Difference Between ipv4 and ipv6”

Find the IP of a Linux Server in Command Line

Knowing your server’s IP address(s) can be a useful bit of information to have for various reasons. After all, other than your domain, the server’s IP is the main address used to reach the server. Knowing a server’s IPs may be necessary when making changes to: DNS, networking, and security. A server may have a single IP, or multiple IPs, sometimes you need a quick way double check since it’s easy to forget.

This tutorial will teach you how to check the IPs of any modern Linux server. To follow along will simply need access to the server via SSH or TTY.

Pre-flight Check:

  • This tutorial requires basic knowledge of SSH and command line.
    See our KB article on command line access via SSH.
  • You must have SSH access to the server.

Check IPs with Command Line

  1. Begin the process by logging into your server via SSH:
    ssh liquidweb.example
  2. Now logged in via SSH, run the following command to check the servers IP:
    ip route

    This command is using the `ip` tool and is calling the `route` object, this command prints the current routing table.

Reading the Results

Once you execute that command you’ll see output similar to the following text. This is showing the servers IP routing table, essentially this is a set of rules used to determine where data will be directed.

When using this technique to find a server’s IPs you’ll keep an eye out for lines containing `src` followed by an IP. On these lines, the IP address following `src` are an IP configured on the server.

default via 203.0.113.1 dev eth0
203.0.113.0/24 dev eth0 proto kernel scope link src 203.0.113.86
198.51.0.0/16 dev eth0 scope link metric 1002
Any device using IP addresses will have a routing table used to determine the devices networking behavior.

In the example results, shown above, you see a severs routing table showing that the server has an IP address of: `203.0.113.86`.

While it may not look like much to new users these lines are dense with information. Each line of the routing table is there to describe a different behavior or condition. More information on these can be found in the ip commands manual pages, these can be found in the command line using `man ip route`. You can also read the man page online here.

Adding IP Addresses to Your Server

Liquid Web allows additional IP addresses to be added to your server for a minimal fee. Having multiple IP addresses on your server can be useful when needing to differentiate domains hosted on your server. With multiple IPs you can setup advanced firewall configurations, use different hostnames with reverse DNS and more.

In any case, if you need to add more IPs to your server LiquidWeb provides a simple process through our Manage interface. Continue reading “Adding IP Addresses to Your Server”

How To Use the IP Blocker in cPanel

  1. This tutorial assumes you’ve already logged in to cPanel, and are starting on the home screen.cpanel-paperlantern-19-ipblocker--01
  2. Now let’s learn how to use the IP Blocker.cpanel-paperlantern-19-ipblocker--02
  3. Click the “IP Blocker” icon.cpanel-paperlantern-19-ipblocker--03
  4. Enter an IP address or range you would like to block, then click “Add”.cpanel-paperlantern-19-ipblocker--04
  5. That’s it! We’ve now blocked anyone using the IP address 123.45.67.89 from accessing our website.cpanel-paperlantern-19-ipblocker--05
  6. You can see which IP addresses are currently being blocked.cpanel-paperlantern-19-ipblocker--06
  7. … and you can remove IP blocks by clicking here.cpanel-paperlantern-19-ipblocker--07

 

How To Unblock Your IP Address in Manage

Liquid Web has introduced a new feature designed to simplify the removal of errant IP address blocks in the firewall, and allow customers to quickly remove their own address from within their Manage dashboard. In this manner, customers can remove blocks on their IP addresses even when they are unable to access WebHost Manager itself due to the block.

Pre-Flight Check

  • The cPanel Quick IP Address Unblock feature is designed for servers using the ConfigServer Firewall (CSF).
  • The feature does not apply to any server utilizing a different firewall.
  • You must have access to your Manage dashboard to use the IP delist feature.
    Note: Customers with Dedicated, Storm, or VPS servers which are not currently using the CSF firewall can request an upgrade from support to take advantage of this Manage feature. There is no charge, it typically takes only a few minutes and the only service that needs to be restarted as a result is the firewall itself. Our support technicians also can port your existing APF rules to CSF. If requesting an upgrade, please be sure to indicate whether your server uses the Guardian backup service so that its rules also can be configured.

Step #1: Log into Your Manage Interface

  1. In Manage, click on the [+] next to your server’s hostname to expand its details.
  2. Now click on the Dashboard button to open the Server Dashboard.Dashboard

Step #2: Unblock the IP Address

  1. Click on the Network tab to bring up the Networking pane.
  2. You will see your current IP address, as reported by your web browser, pre-populated in the cPanel Quick IP Address Unblock field. If you wish to unblock a different IP address, simply replace the address shown in the field with the IP address you wish to unblock.
    If you’re attempting to unblock the IP address of a client, developer, or other party who does not know their public IPV4 address, you can direct them to http://ip.liquidweb.com to obtain their address for you.
  3. Click the Unblock IP button to attempt to automatically remove the IP address in the CSF firewall.Unblock
  4. The Unblock IP button will change to Working… while it attempts to delist the IP address. Once the process completes, you should see a banner indicating whether the delisting was successful.Success

Step #3: I Got Blocked Again. Why?

There are many reasons why an IP address can be blocked in the firewall, but the two most common are:

  • The use of an incorrect username or password combination when connecting to the server or a service such as email, ftp, ssh, or cPanel/WHM
  • A mod_security rule violation

If you are unable to determine the cause for the block, feel free to contact Heroic Support®. You also may wish to consult the following Knowledge Base articles: Unblocking an IP Address or Opening a Port in the Firewall and How to Manage the CSF Firewall in WHM/cPanel.

Error: /usr/sbin/ifconfig: No such file or directory [SOLVED]

Pre-Flight Check
  • These instructions are intended specifically for solving the error: /usr/sbin/ifconfig: No such file or directory
  • I’ll be working from a Liquid Web Self Managed CentOS 7 server, and I’ll be logged in as root.

Continue reading “Error: /usr/sbin/ifconfig: No such file or directory [SOLVED]”