Remote Desktop Users Group

The most common way to remotely manage a Windows server is through Remote Desktop Protocol. By default, Liquid Web’s Windows servers only allow the members of the administrators’ group remote desktop access. However, the Remote Desktop Users group grants its members access to securely connect to the server through RDP (Remote Desktop Protocol) as well.

This article will go over the basics of the Remote Desktop Users group. By the end, you will be able to add users to the group, understand permissions, and basic user management.

 

Pre-flight

The information below covers methods to configure the Remote Desktop Users group for Windows Server 2012 through Windows Server 2016 on any Liquid Web Windows server. As a valued customer, if you do not feel comfortable performing these steps independently, please contact our support team for additional assistance. Liquid Web support is happy to walk you through the steps and answer any questions you may have.

 

Managing Local Users and Groups

Users and groups on Windows servers are managed in a number of different ways, but the most user-friendly way is through the Local Users and Groups interface. There are several ways to open the interface. However,  the easiest is to run “lusrmgr.msc”. Lusrmgr.msc can be launched by searching the start menu, command line, or through a run dialog. These methods allow you to find users and groups easily.

Note
To manage local users and groups, you will need to be logged in with a user that has the proper permissions to do so. This is most commonly a user that is already a member of the Administrators group.
Within a windows server type in lusrmgr.msc into the search bar to locate Users where you can find existing users and groups.

 

User Management

Once you open the Local Users and Groups interface, you will see two folders on the left, one for Users, and one for Groups. By selecting Users, you will see a full list of local users on the server. You can also see a variety of related tasks by right-clicking Users, Groups, a user’s name, or a blank area of the middle pane.

There are several ways to add a new user through the Local Users and Groups interface. These methods all result in the same “New User” dialog box opening where you can then configure a Username, Password, and other options. Choose one of the options below to create a new user:

  • With the Users folder selected in the left pane, click the Action menu, then select “New User…”.
  • With the Users folder selected in the left pane, click “More Actions” from the right- hand pane, then select “New User…”.
  • Right-click the Users folder, then select “New User…”.
  • With the Users folder selected in the left pane, right-click in a blank area of the middle page, then select “New User…”.

Once you have created a new user, or have identified the username of the existing user, you are ready to assign that user to a Group. Users assigned to a group are known as group members.

 

Group Management

As with user management, group management can also be performed in several ways. The options below cover several of the most common ways to assign a new member to the Remote Desktop Users group:

  • Select the Users folder from the left pane of the Local Users and Groups interface, open the Users Properties window by double-clicking the user, select the “Member Of” tab, then click “Add…”. Now type “Remote Desktop Users” in the text box and click OK.
  • Select the Groups folder from the left pane of the Local Users and Groups interface, double-click the “Remote Desktop Users” group, click “Add…”, enter the user’s name in the text box and click OK.
  • Open the system settings by right-clicking the start menu and selecting “System”, choose “Advanced system settings”, select the “Remote” tab, click the “Select Users…” button then click the “Add” button. Now enter the user’s name in the text box and click OK.
  • Open the “Server Manager”, select “Local Server” from the left pane, click the blue text next to “Computer Name”, select the “Remote” tab, click the “Select Users…” button then click the “Add” button. Now enter the user’s name in the text box and click OK.
    Note
    When selecting users or groups, it is recommended to click the “Check Names” button after typing in the user or group name. If the name is underlined after clicking the “Check Names” button, then the name was identified correctly.

You can also use the “Advanced…” button when selecting users or groups instead of typing its name. Clicking the “Advanced…” button followed by the “Find Now” button will result in a list of users to select.In a windows server, by right-clicking the User folder you can do a variety of tasks like adding a new user.

 

Notes on Permissions & Security

By default, there are no members of the Remote Desktop Users group and only members of the Administrators group are allowed to connect through RDP. Members added to the Remote Desktop Users group are considered non-Administrative users. These users will be unable to perform most management tasks such as installing software, managing IIS, or rebooting the server.

If a user requires management abilities, the user will need explicit access to that task or will need to be a member of the Administrators. Please use the best practice of “least privilege” when configuring your users, groups, and permissions.

 

Test/Verify Group Membership

When configuring new user and group memberships, you should always review group membership once complete.  Reviewing group membership is most commonly performed through the Local Users and Groups interface. In addition to verifying membership, we also recommend attempting a remote desktop connection with your newest Remote Desktop Users group member. If you are unable to connect with your user, please see our Remote Desktop Troubleshooting article.

Once you have logged in with your newest member of the Remote Desktop Users group, you can further verify that groups are set up correctly by running the command “whoami /groups” from a command line. The output of this command lists the username and its associated Group names.

 

HIPAA Compliant Hosting Checklist

HIPAA Compliance

In this guide, we outline the essential requirements for HIPAA compliant servers and how Liquid Web helps fulfill these necessities.

HIPAA, or the Health Insurance Portability and Accountability Act of 1996, was passed by Congress to protect sensitive user information related to health insurance. This act helps to reduce health care fraud and mandates a standard for handling confidential healthcare information for consumers and businesses.

HIPAA compliance protects this sensitive information and specifies proper guidelines and standards for handling health insurance data. HIPAA also establishes rules for handling, administering, and maintaining electronic servers as well as the hosting of this Protected Health Information.

Read more here: https://www.liquidweb.com/kb/what-is-hipaa-compliant-hosting/

Key Terms and Important Information:

HIPAA – Health Insurance Portability and Accountability Act of 1996

PHI – Protected Health Information

Access Control – To limit who can log in or access sensitive PHI data. Access control helps provide accountability for authorized usage and access to servers with confidential information. HIPAA requires that all users are uniquely identifiable and that the server hosting PHI data is only accessible to specifically authorized users and entities.

Audit Control – To log and record hardware, software and procedural work done to maintain and repair HIPAA compliant servers and data centers. HIPAA requires accurate and uniquely accountable logs for the type of work performed, what was accessed, and by whom. This notation is closely related to access control by limiting maintenance to authorized and uniquely identifiable persons or entities, but also refers explicitly to logging any maintenance of physical hardware or server software.  

Facility Access Control – To limit physical access to the data center from unauthorized or unaccountable persons. This control makes sure that only designated workers have access to physical servers containing PHI. Liquid Web’s data centers are HIPAA compliant and properly limit access to all servers.

To be HIPAA compliant, you must have firewalls in place. Most of the time, compliant hosting will implement hardware, software, and application level firewalls to protect the server from unauthorized users. This security applies to Access Control as well as Transmission Security, which protects PHI from unauthorized access.

HIPAA regulations state the firewalls must be system-wide. The firewall implementations are part of the requirements for limiting access to personal information stored on the server. Firewalls that are properly setup will limit or prevent accessibility from anyone who should not have access, often using explicit whitelists and blacklists. This setup prevents unauthorized employees, clients, or hackers logging into servers with sensitive data.

To be allowed through the firewall your users must have a uniquely identifiable username or identification that has been explicitly allowed access permission.  At Liquid Web, our networking team is at hand to secure your server with hardware firewalls, while our support team is ready to protect sensitive PHI data with software firewalls.

HIPAA compliance requires that remote access to the server through an encrypted VPN tunnel. This VPN protects data entering into the tunnel with an encrypted session that lasts only as long as the session exists. Work done between the remote workstation and the server is protected from interception via this encryption. At Liquid Web, our VPN services are automatically encrypted in order to protect your data.

Password management is an essential part of HIPAA compliance. Safeguarding passwords and isolating them to identifiable users is integral to the protection of sensitive data. Using multi-factor authentication is highly recommended for this process.

Multi-Factor Authentication forces users logging into the secured server system to use both a password and another form of authentication, such as a mobile device, verifying their identity for granting intended access. Authenticating makes it much more difficult for hackers and unauthorized users to use stolen or brute force-acquired login credentials to access the server, as the user will have to do a secondary verification from a device that is unique to them.

Many companies utilize Google Authenticator which allows your users to have a phone app to use as their secondary verification method. Multi-Factor Authentication falls under Access Control.

If you want to be HIPAA compliant, your server cannot be on shared hosting. You must have a server that cannot be accessed by any other business or entities, which means it needs to be private or dedicated to your business. This isolated includes requiring a private IP address that is not used by another entity.

By running on shared hosting, you are breaking HIPAA compliance by allowing non-authorized users access to the server. Hosting with Liquid Web gives you your own private, dedicated server strictly used by your business.

HIPAA requirements for limiting user access and having proper authentication. The server itself must also exist within a HIPAA compliant data center. Liquid Web has a high-security, HIPAA compliant data center that all of our clients are hosted within, falling under Facility Access Control.

An SSL certificate must protect any part of your website where sensitive information can be accessed.  An SSL provides end-to-end encryption for the accessed data and logins used, to further protect access to the server. HIPAA defines PHI as Protected Health Information and anywhere that a user can access PHI must be protected with SSL.

For more information about SSL and how it works, click here: https://www.liquidweb.com/kb/how-does-an-ssl-work/

A BAA is necessary for HIPAA compliant hosting as it designates the role of the hosting company and defines responsibility for different parts of HIPAA compliance. It does not resolve your business of its HIPAA related duties, but it represents the roles that your business and the hosting company partake.

This Business Associate Agreement allows a hosting company the necessary access to servers to maintain them, while still preventing any other businesses’ unauthorized access to Protected Health Information.

See our HIPAA BAA policy here: https://www.liquidweb.com/about-us/policies/hipaa-baa/

HIPAA compliance requires that all Protected Health Information must have an exact backup ready for restoration. These backups must also be located offsite and not on your server for recovery in the event of disaster or server malfunction. At Liquid Web we have two solutions for this, Guardian and DPM Backups.

By having an offsite backup, you are protecting the Protected Health Information and ensuring that no data loss will occur on restoration. Fully restoration is often achieved with continuous backups notating any changes of information on the server.

Read more about our different backup services here: https://www.liquidweb.com/products/add-ons/storage-backups/

To be HIPAA compliant, the appropriate methods are necessary for getting rid of hardware. This disposal usually requires that the data be wiped entirely and destroyed in a manner that will not allow for restoration.

Data destruction is typically peer-reviewed and documented to state precisely the method of destruction. This process is to prevent any future use of the hardware from being able to recover sensitive PHI data.  Often called Integrity Control it ensures that data is properly altered or destroyed.

All logins and maintenance must be fully documented. Any repairs on the physical servers must be logged, especially those related to the security of the server and who logs in to servers for software maintenance and reviews and applies to Audit Control.

At Liquid Web, all of our work is logged and appropriately recorded with HIPAA compliant standards.

HIPAA compliance is an integral part of your business. While it can be confusing, our technicians at Liquid Web can ensure you that your Protected Health Information is appropriately handled and follows HIPAA compliant standards. While we have only reviewed a portion of the requirements of HIPAA compliance, feel free to reach out to our HIPAA Specialists for more information about how we handle our data centers and servers.

If you would like to speak with a HIPAA Specialist, start here: https://www.liquidweb.com/solutions/hipaa-compliant-hosting/

SSL vs TLS

You may have first heard about TLS because your Apache service needed to be secured using TLS for a PCI scan (Payment Card Industry: PCI scans are a standard to ensure server security for credit card transactions). Or maybe you noticed that your SSL also mentions TLS when you are ordering the certificate. Beyond where you heard the names, the question is, what is this mysterious TLS in relation to SSL and which of the two should you be using?

So what is the difference between SSL and TLS? Surprisingly not much. Most of us are familiar with SSL (Secure Socket Layer) but not TLS (Transport Layer Security), yet they are both protocols used to send data online securely. SSL is older than TLS, but all SSL certificates can use both SSL and TLS encryption. Indeed SSL certificates are appropriately called SSL/TLS certificates, but that becomes a mouthful. Thus the industry has stuck with calling them SSLs. From here on out I will break from convention and call the actual certificate an “SSL certificate” to distinguish the encryption type from the certificate. SSL has its origins in the early 1990s. The mention of Netscape and AOL should date how old these protocols are as they are the first to coin the term SSL.

 

Green Lock On Webpage

If you look up to the upper left corner of this webpage, you may see a very tiny lock and the word “Secure” written in green. While that doesn’t look like much, it plays a critical part of security. The SSL is what your web browser uses to show that data sent from your computer is safe. SSL certificates create a secure tunnel for HTTPS communication. HTTPS stands for Hyper Text Transfer Protocol Secure, differentiating from HTTP, (Hyper Text Transfer Protocol) which has no SSL present. If you see a red lock or a caution sign in the corner of your web browser, that indicates that the connection is not encrypted. Meaning a malicious third party could read any data sent on that webpage.

A secure connection happens via what is called a “handshake” between your browser and the web server. A simplified explanation of this is that the server and your browser agree on a literal “secret” handshake between each other based upon the type of encryption (SSL/TLS) and the SSL certificate itself. This handshake forms its encoding from the interaction of the public and private certificate key. From that point onward they use this secret handshake to confirm the information sent back and forth is from the authentic source.

This handshake and the accompanying SSL certificate helps prevent a man in the middle attack between customers and a server-side business. A man in the middle attack is where a malicious entity intercepts communication between a server and your computer. The man in the middle receives requests from the user and passes along the information to the server and back again. Data between the end user and the server are read, hence “man in the middle” phrase. If attacked, the Man in the Middle technique will show passwords and other sensitive information. As terrifying as that sounds this attack is only possible if there is no SSL certificate on the site.

As you may have heard, Google and FireFox are phasing out non-SSL/TLS encrypted websites. The change will soon show an explicit warning with the browsers for any site that is not covered by an SSL certificate. The browsers will force an acknowledgment that you want to proceed with an insecure website before showing any content.

For business owners who accept online payments, it is even more critical to not only have an SSL certificate but also enforces the latest TLS versions on the server. In a PCI compliance scan, it requires that the domain only use specific TLS versions.

SSL and TLS each have specific versions which relate to the type of encryption that the SSL certificate will use in the previously mentioned handshake.

The SSL versions are:

  • SSL v1
  • SSL v2
  • SSL v3

Never released to the public but still notated is SSL v1; SSL v2 was an improvement upon SSL v1 but still problematic; SSL v3 fixed some of these initial bugs but is open to attacks through vulnerabilities like POODLE or DROWN (read more on those vulnerabilities here). SSL v3 was at the End of Life in 2015, forever ago regarding the internet.

Modern TLS encryptions cover:

  • TLS v1.0
  • TLS v1.1
  • TLS v1.2
  • TLS v1.3

Each of which addresses flaws from one version to the next. The newer encryptions are just that, more modern and more secure ways to encrypt data for security. The later the release, the better the encoding and the more difficult it is to decrypt by malicious third parties. Conversely, the older versions, like with SSL, have vulnerabilities which can be exploited to collect private data. In many ways, you can think of TLS as the newer version of SSL. Some refer to TLS v1.0 as TLS v 1.0/SSL v3.1.

For the interested technophile, as it relates to the handshake example, we break down the first connection process. The first connection deals with the browser, and a “browserhello” is the first exchange in the handshake. The browser then states the version of TLS they accept, say, for example, everything up to TLS v1.1. The server then replies with a “serverhello,” which is the second exchange in the handshake. The server states the version of encryption that is for the rest of the interaction based upon the first connection.

This interaction should force the newest version of SSL/TLS that both the server and browser are capable of handling. Some outdated browsers do not use the latest versions of TLS. The server is also capable of disabling specific TLS/SSL versions, ensuring all the connections to the server are safer. In this way, new servers should disable the use of all SSL versions and even some of the TLS versions. For example, as of September 2018, PCI certification require all SSL versions and TLS v1.0 disabled.

So back to our original question, what is the difference between SSL and TLS? In sum, TLS is the logical progression of SSL and the safer of the two by that fact. Beyond this, they work in the same fashion, but the newer versions use stronger types of encryption.

If you are interested in getting an SSL for your website, check out our blog to help you make an informed decision on what kind of SSL to purchase.

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.

 

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.

How to Add a User and Grant Root Privileges on Ubuntu 16.04

Ubuntu 16.04 LTS provides you the ability to add a user for anyone who plans on accessing your server.  Creating a user is a basic setup but an important and critical one for your server security. In this tutorial, we will create a user and grant administrative access, known as root, to your trusted user.

 

Pre-Flight Check

  1. Open a terminal and log in as root.  
  2. Work on a Linux Ubuntu 16.04 server

Step 1:  Add The User

Create a username for your new user, in my example my new user is Tom:

adduser tom

You’ll then be prompted to enter a password for this user.   We recommend using a strong password because malicious bots are programmed to guess simple passwords. If you need a secure password, this third party password generator can assist with creating one.

Output:

~# adduser tom
Adding user `tom' ...
Adding new group `tom' (1002) ...
Adding new user `tom' (1002) with group `tom' ...
Creating home directory `/home/tom' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Note
Usernames should be lowercase and avoid special characters. If you receive the error below, alter the username. ~# adduser Tom
adduser: Please enter a username matching the regular expression configured via the NAME_REGEX[_SYSTEM] configuration variable.  Use the `--force-badname' option to relax this check or reconfigure NAME_REGEX.

 

Prompts will appear to enter in information on your new user.  Entering this information is not required and can be skipped by pressing enter in each field.

Enter the new value or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:

 

Lastly, the system will ask you to review the information for accuracy.  Enter Y to continue to our next step.

Is the information correct? [Y/n]

 

Step 2: Grant Root Privileges

Assigning a user root access is to grant a user the highest power.  My user, Tom, can then make changes to the system as a whole, so it’s critical to allow this access only to users who need it. Afterward, Tom will be able to use sudo before commands that are usually designed to be used by the root user.

usermod -aG sudo tom

 

Step 3: Verify New User

As root, you can switch to your new user with the su – command and then test to see if your new user has root privileges.

su - tom

If the user has properly been granted root access the command below will show tom in the list.

grep '^sudo' /etc/group

Output:

sudo:x:27:tom

 

Malware – How to Detect and Remove

Maldet, a free popular malware scanning software for Linux servers, can be used to scan an entire server for potentially malicious files. Properly configured and monitored, it can even be used to disable or fully remove malware when it is detected. However, the removal of files should only be configured once you are certain no false positives will be picked up in the scans.

 

How to Install Maldet

To Install Maldet on your linux server copy and paste the following into the command lines. Maldet will then be pre-scheduled to run daily.

pushd /usr/local/src/
rm -vrf /usr/local/src/maldetect-*
rm -vrf /usr/local/src/linux-malware-detect*
wget http://www.rfxn.com/downloads/maldetect-current.tar.gz
tar -zxvf maldetect-current.tar.gz
cd maldetect-*
sh ./install.sh
maldet --update-ver
#sed patch - commands added to address current problem with maldet overriding values in the conf file
sed -i 's/quarantine_hits=\"1\"/quarantine_hits=\"0\"/' /usr/local/maldetect/conf.maldet
sed -i 's/quarantine_clean=\"1\"/quarantine_clean=\"0\"/' /usr/local/maldetect/conf.maldet
sed -i 's/email_alert=\"1\"/email_alert=\"0\"/' /usr/local/maldetect/conf.maldet
sed -i 's/email_addr=\"you@domain.com\"/email_addr=\"\"/' /usr/local/maldetect/conf.maldet
#end sed patch
maldet --update
if [ -e /usr/local/cpanel/3rdparty/bin/clamscan ] then
ln -s /usr/local/cpanel/3rdparty/bin/clamscan /usr/bin/clamscan
ln -s /usr/local/cpanel/3rdparty/bin/freshclam /usr/bin/freshclam
if [ ! -d /var/lib/clamav ] then mkdir /var/lib/clamav
fi
ln -s /usr/local/cpanel/3rdparty/share/clamav/main.cld /var/lib/clamav/main.cld
ln -s /usr/local/cpanel/3rdparty/share/clamav/daily.cld /var/lib/clamav/daily.cld
ln -s /usr/local/cpanel/3rdparty/share/clamav/bytecode.cld /var/lib/clamav/bytecode.cld
else
echo -e "\n\e[31mClamAV does not appear to be installed through cPanel.\nThe ClamAV definitions will not be used.\e[39m\n"
fi
Popd

Scanning for Malware

Once you have completed the installation you will want to configure the scanning process. The configuration for maldet is located /usr/local/maldetect/conf.maldet. You will want to open the file with your favorite text editor such as vim or nano:

vim /usr/local/maldetect/conf.maldet
Once you are editing the file you will want to add your email address between the “ “ on the line email_addr=,  like so email_addr=“myemail@mydomain.tld”

You can also set up the scan to quarantine the malicious files it finds by changing the line quarantine_hits= from “0” to “1”, it should look like quarantine_hits=“1”. I would advise against this option as it can pick up legitimate code mistakenly. If the scan does mistakenly place a legitimate file into quarantine, you will need to move it back into place by using the following command template, replacing SCANID with the proper scan ID reported by maldet:

Maldet --restore {SCANID}
Once you have run the scan with quarantines for some time and you are confident that no safe files are being picked up, you may want to turn on removal of quarantined files in the same configuration /usr/local/maldetect/conf.maldet at the line quarantine_clean= from “0” to “1” , it should look like quarantine_clean=”1”. I would personally avoid this configuration option as it can always pick up new edits mistakenly and destroy your hard work.

Looking for pre-configured protection for servers and websites? Check out our wide security offerings that are sure to fit any of your security concerns!

Upgrade PHP 5.6 to 7


PHP is a programming language that can run with Apache or Microsoft IIS and works with your server to execute the requests that make up your website. 88% of online sites run on, soon to be vulnerable PHP 5.X technology. At the close of this year, scheduled by Dec 31, 2018 security support will end for our dear old friend PHP 5.6, meaning bugs and security fixes will not be tended to and could lead to security vulnerabilities. 
Each PHP version gets supported actively for two years while the third year only gets critical security updates. Luckily, the PHP gods had smiled upon us and extended the life for just a year longer than the typical PHP version before giving us the new year deadline. For all of you developers out there wanting to know exactly what is changing, here’s a helpful migration guide from PHP 5.6 to PHP 7.X.

While the last of PHP 5 closes out with PHP 5.6, this will inevitably leave websites utilizing PHP 5 vulnerable to attacks as well as poor performance. It has substantially reached its infamous End of Life (EOL) title. Switching to the newer PHP 7 versions is not only good for the security, but updating can ultimately save you money. Reducing the cost of doing business by avoiding software incompatibility and compliance issues. If an emotional headache isn’t enough to persuade developers to switch, the benefits will. Benchmarks show PHP 7.x has been tested to run three times faster than PHP5.6!

Let’s see:

  • Faster performance resulting in less memory usage
  • Three times faster page loads*
  • Better for heavy traffic sites
*Performance increase as benchmarked in a testing environment. Other developer’s website performance changes between PHP 5 and PHP 7 may vary.

If you are in a shared environment that manages the OS and framework, then your hosting provider should be sending out notifications of the upcoming change, their plan of action, and cut off dates. Our managed hosting products, such as Storm VPS, Cloud Sites or Managed WordPress, have support teams that can help you switch from PHP 5.X to PHP 7.X easily. Our Managed WordPress product has a compatibility checker built in & one click button to upgrade, yet another reason to love it!


While using WordPress to power your site you can check some vital aspects by going to the
WordPress plugin page and searching for the plugins that you use. Once you find the plugin or themes that you utilize, their spec pages will usually say what PHP version they employ. Also, check out the review tab for comments from users as this section gives useful information. This review tab is helpful for seeing if others have had issues with the plugin or theme and newer PHP versions. It is good practice to look up reviews and see what people have been saying about said plugin. If you don’t see any responses or it hasn’t rated well, then you will want to stray away from it. If you use custom plugins, check with your developer to see how they operate in new PHP versions. The WordPress Compatibility Plugin check will give you a list of plugins and themes that may not mesh well with PHP 7.X.

If you run a mission-critical site its best to do a compatibility checker because blindly upgrading could result in some parts of your page to not function. Checking PHP compatibility, as you would imagine, is a little more in depth but from research online, there is a compatibility checker for VPS servers that you can utilize by downloading the repo from GitHub.

It is worthwhile to note that some plugins may need a PHP module to be installed for the plugin to work. When upgrading the PHP version, you may also need to re-install the PHP module. Fortunately, our support team can assist with installing any PHP module you may need or give the best course of action if the PHP module is not available for your PHP version.

If you are using a Linux VPS the easiest way to check is to ssh into your server and run the following command via your terminal:

php --versionOutput: PHP 7.0.30 (cli) (built: Jun 26 2018 20:34:16)

cPanel:

Note
It’s important to make a backup of your site before migrating to PHP 7.X

Search php, select Multi PHP Manager, will show this screen to show which php version you are using. While on the PHP Version screen you can update the PHP version here by clicking on the check mark next to the domain and selecting the desired PHP version on the right drop down and click Apply.

Search For PHP and Click MulitPHP Manager Icon

The Best Ways to Secure WordPress

On our Managed WordPress hosting platform, we strive to ensure security with regularly scheduled patches and updates. By utilizing our intrusion prevention software, we mitigate malicious activity and block repeated failed logins for your WordPress admin portal. Furthermore, our web-application firewall, restricts unneeded ports along with custom rules to help protect you on the application level. We take care of the administration work so you can spend more time securing your site. Below our Managed WordPress admins share tested (and trusted) implementations to keep your site locked up tight.

WordPress Security Plugins

iThemes Security

The iThemes Security plugin is a fantastic addition to enhance your security, and it is easy to install.  By adding an extra layer of protection, below is a list of security features that iThemes Security Pro provides.

Click To See iThemes Security Features
    • Banned Users – Allows you to completely ban hosts and user agents from your site
    • Network Brute Force Protection – Banning users who have tried to break into other sites from breaking into yours. The network protection will automatically report the IP addresses of failed login attempts to iThemes
    • SSL – This feature redirects all http traffic to https
    • Strong Password Enforcement – Force users to use strong passwords as rated by the WordPress password meter
    • System Tweaks:
      • Disable Directory Browsing
      • Filter Suspicious Query Strings in the URL
      • Remove File Writing Permissions – Prevents scripts and users from being able to write to the wp-config.php file and .htaccess file
      • Disable PHP in Uploads – Disable PHP execution in the uploads directory. This blocks requests to maliciously uploaded PHP files in the uploads directory.
      • Disable PHP in Plugins – Disable PHP execution in the plugins directory. This blocks requests to PHP files inside plugin directories that can be exploited directly.
    • Change WordPress Salts – Use WordPress Salts to encrypt any passwords saved within WordPress, this adds an extra layer in password protection. Check this box and then save settings to change your WordPress Salts.

Salt Encryption Settings

  • WordPress Tweaks:
    • Comment Spam– Reduce Comment Spam
    • XML– RPC feature allows external services to access and modify content on the site. Common example of services that make use of XML-RPC are the Jetpack plugin, the WordPress mobile app, and pingbacks. If the site does not use a service that requires XML-RPC, select the “Disable XML-RPC” setting as “disabling XML-RPC” which prevents attackers from using the feature to attack the site. Disable Pingbacks – This feature only disables pingbacks. Other XML-RPC features will work as normal. Select this setting if you require features such as Jetpack or the WordPress Mobile app.
    • Block XML– RPC requests that contain multiple login attempts.
    • Restricted Access– Restrict access to most REST API data. This means that most requests will require a logged in user or a user with specific privileges, blocking public requests for potentially private data.
    • Force Unique Nickname– This forces users to choose a unique nickname when updating their profile or creating a new account which prevents bots and attackers from easily harvesting user’s login usernames from the code on author pages. Note this does not automatically update existing users; it will affect author feed urls if used.
    • Protect Against Tabnapping– Alter target=”_blank” links to protect against tabnapping. Enabling this feature helps protect visitors to this site (including logged in users) from phishing attacks launched by a linked site.
    • Login with Email Address or Username– By default, WordPress allows users to log in using either an email address or username. This setting allows you to restrict logins to only accept email addresses or usernames.

To install, login to your WordPress dashboard, click on “Plugins” on the left. Click on “Add New” and use the search box to find “iThemes Security (formerly Better WP Security)”. Click on “Install Now”, and then activate the plugin.  On the left bar, click on “Security” and iThemes will start a security check on your site.  Additionally, you can click on Security > Settings on the left to enable any security features that fit your website.

WordFence

Wordfence Security – Firewall & Malware Scan plugin – Wordfence includes an endpoint firewall and malware scanner.  One of the key features is their threat defense feed arms that are supplied with the newest firewall rules, malware signatures and malicious IP addresses to keep your website safe.  Click on the Wordfence subtitle to jump to installation and setup instructions.

CloudFlare

You can create an account with CloudFlare to help protect your websites from various attacks including DDoS mitigation, customer Cloudflare helps mitigate DDoS attacks, prevent customer data breaches, and block malicious bot abuse. Cloudflare DNS is DDoS protection for domain resolution. It sits behind the same 15 Tbps network that protects over 7 million Internet properties from denial-of-service attacks.  Cloudflare DNS also comes with built-in load-balancing, automatic failover, rate-limiting, and filtering. Cloudflare also offers DNSSEC to add a layer of trust on top of DNS by providing authentication.

Web Application Firewall (WAF)

Web application firewall (WAF) rulesets – Available on all of Cloudflare’s paid plans, the WAF has built-in rulesets, including rules that mitigate WordPress specific threats and vulnerabilities. Additional features: automatic cache purge, and header rewrite to prevent a redirect loop when Cloudflare’s Universal SSL is enabled.  You can change Cloudflare’s settings from within the plugin itself without needing to navigate to the cloudflare.com dashboard. The available settings to change are: cache purge, security level, Always Online, and image optimization.

Sucuri

As an auditing, malware scanner, and security hardening plugin, it’s a security suite that works well with your existing website’s  security. This plugin offers a great set of security features such as Security Activity Auditing, File Integrity Monitoring, Remote Malware Scanning, Blacklist Monitoring, Effective Security Hardening, Post-Hack Security Actions, Security Notifications, and Website Firewall (premium).

General Security Recommendations

We are living in an age where security needs to be updated at all times. Passwords is one of those crucial security mechanisms that needs to be updated at least every 30 to 60 days. The recommendation for each password complexity is to be at least 15 characters containing a combination of uppercase letters, lowercase letters, numbers, and symbols. The passwords should not contain dictionary words, usernames, personal information, or letter sequences. The passwords should not be reused in a given year.

Along with having secured passwords, your computer should also be protected.  Attackers can exploit computers that have outdated operating systems using worms, malware, Trojans, and viruses. You will need to make sure your computer has the latest security patches and fixes.  All browsers should be the latest versions. Do not install any software or browser plugins from any untrusted parties.  Install reputable anti-virus software and conduct regularly malware scans on your computer.

The most common source for malicious injections are vulnerabilities in CMS software, plugins, themes and other commonly used third party code. We recommend taking measures to update all CMS software, plugins and themes used to the latest versions available from their respective vendors. This would help limit the chance of future infections occurring.

Registering your website with Google Webmaster Tools will tell you the health of your website. Change the Default “admin” username.  Since usernames make up half of login credentials, having the username “admin” made it easier for hackers to do brute-force attacks.

Final Thoughts

Being at the top of your game on security is worthwhile to avoid paying expensive fees to clean up a hacked site, especially since there are many free security options at your disposal. Take a stroll through our Managed WordPress product page and discover how we can take the guesswork out of security. Along with a 24/7 support team at your fingertips, our Managed WordPress platform automatically updates plugins to reduce your site’s vulnerability to malware.