Every web hosting provider offers site management solutions so that customers can customize their domain settings and manage their sites independently. DirectAdmin is one of the most popular tools on the market, similar to Plesk (discover Plesk security best practices) and cPanel (learn more about cPanel security). After deployment, server administrators and site owners should review configurations and follow cybersecurity best practices to protect sites from exploits and safeguard sensitive data. Although this guide does not reduce risk by 100%, following it will improve your cybersecurity posture and stop many common threats that could harm hosted sites. In this article, you will learn about DirectAdmin and discover DirectAdmin security best practices:
Why is Securing DirectAdmin Important?
Best Practices for DirectAdmin Security
- Mount /tmp Partition with noexec and nosuid Options
- Disable Dangerous PHP Functions Using the disable_functions List
- Regularly Update System Services and Libraries
- Configure safe_mode and open_basedir in PHP CLI Mode
- Install suPHP
- Bind MySQLd to 127.0.0.1 (Localhost)
- Add Apache mod_security
- Force DirectAdmin to Use Newer SSL/TLS Versions
- Block Apache Users from Executing Perl Scripts
- Disable Direct Access to SSH for the root User
- Turn On Brute-Force Detection
- Use Secure Email Connections
- Disable UserDir Access
- Install Anti-Malware Extensions
Recommended Articles
What is DirectAdmin?
Without a site management solution, server administrators would be responsible for configuring user sites, which is inefficient for large organizations. Site management tools empower site owners so that they can configure their sites without intervention from server administrators. DirectAdmin is one of these tools, along with other popular choices such as cPanel and Plesk. Server administrators can configure the main DirectAdmin application, but site owners have options to configure their sites individually. This gives site owners control over their own sites and administrators control over the server itself.
Web hosters must deploy the application to Linux servers, but site owners are responsible for their own configurations. Site owners can manage their domain setup, FTP, MySQL databases, email accounts, SSL certificates, DNS, and several other applications.
Why is Securing DirectAdmin Important?
Every day, hackers find exploits in software, some low severity and others critical and widespread across the internet. In some cases, it isn’t until a vulnerability is exploited that software developers are aware of it and deploy patches.
DirectAdmin has a few CVEs to be aware of, so it’s important for server administrators to stay on top of the recent DirectAdmin updates and patches and harden the software against common threats.
Site owners should also stay updated on the latest attacks, but many of them do not. Not only do website owners rarely keep track of the latest CVEs, but at times they also don’t know the configurations that could open the site up to exploits. With some organized best practices, server administrators and site owners could draw guidance on how to harden security on a server and protect from common attacks. Just one vulnerability could lead to site defacing, malware installed on the server, privilege escalation and account takeover, ransomware, or email spam using the targeted victim’s hacked account.
Best Practices for DirectAdmin Security
DirectAdmin gives a lot of control to website owners, which benefits both the site owner and server administrators. With these configurations, administrators can protect from common attacks and focus on other security issues that could threaten the integrity of sites on the server. Remember that these configurations do not reduce risk 100%, but they will help site owners avoid many common attacks.
Mount /tmp Partition with noexec and nosuid Options
Partitioning server storage space is a common security strategy for server administrators. The /tmp directory contains files used only temporarily, but they could be used to install malware on the server. Some files are critical for running programs, but the /tmp directory could also be used as a vector for attackers to store and execute malicious programs.
A common Linux administration strategy to secure this directory from attacks is to partition it with noexec and nosuid options. The noexec option prevents program execution from the /tmp directory, and the nosuid mount option prevents the setuid flag from being set in file permissions.
If you are unsure about the current state of your partitions and their configurations, type the following command to view current partitions:
mount
Note: Make sure you edit the /etc/fstab file correctly, because errors in this file can prevent the system from booting.
Configuration of the /tmp partition is defined in the /etc/fstab file. To configure the partition with noexec and nosuid, follow these steps:
- Edit the /etc/fstab file by typing:
# vi /etc/fstab - Find the following line in the file:
UUID=0aef28b9-xxxxxxx /tmp ext4 defaults 1 2 - Edit this line with the options so that it reads like this:
UUID=0aef28b9-xxxxxxx /tmp ext4 defaults,nosuid,noexec 1 2 - Save and close the file.
ln -s <old_tmp_directory> <new_tmp_directory>
Disable Dangerous PHP Functions Using the disable_functions List
Some PHP functions pose a threat to server integrity when left enabled. For example, the shell_exec() function lets you execute a command via a shell and return the output to the user. Unless you absolutely need this function enabled, it’s best to disable it. Many hackers add this function (and others) to their exploit scripts to identify if it can be executed by public users. This vulnerability can be removed using a disable_functions list in Apache by editing the custom build on DirectAdmin.
To disable dangerous PHP functions, follow these steps:
- Switch to the custombuild directory by typing:
$ cd /usr/local/directadmin/custombuild - Update the disable_functions configuration by typing the following:
./build set secure_php yes
./build secure_php
Regularly Update System Services and Libraries
Every application still maintained by the developer has version releases and patches. Patches and updates usually address bugs and security issues. Older versions are usually retired, so developers no longer maintain the code. Once retired, the older software version should be updated.
Site libraries and any code on individual websites must be updated by the site owner, but the server administrator must also keep system resources up to date. Site owners can update libraries using their own methods or the software update features. For example, site owners can use WordPress to download and update third-party plugins and the core codebase.
Low-level services can be updated using yum or apt-get, but to update DirectAdmin services and scripts, run the following commands:
cd /usr/local/directadmin/custombuild
./build update
./build all d
Configure safe_mode and open_basedir in PHP CLI Mode
Just like the disable_functions list, running PHP in safe-mode protects the server from exploitable code when the system runs it in a command-line interface. Several PHP functions can be used to run scripts on the server that, in turn, can be used to elevate privileges, steal data, or upload malware.
You can disable open_basedir in the DirectAdmin interface. Go to:
PHP SafeMode Configurations -> Php Safe Mode Settings
In this interface page, disable open_basedir.
To configure PHP to run in safe mode, you must edit the php.ini file. Open the file and find the line with the safe mode configuration:
safe_mode = Off
Change this line to the following:
safe_mode = On
Install suPHP
PHP scripts normally run with a specific user, “Nobody,” across all scripts, which means if an attacker gains access to this specific account, the attacker can execute any script that runs under the target account. It also limits site owner’s ability to operate files to only the files that they upload to the server, so any malicious code uploaded from a site owner account or a compromised low-privileged account would not be able to run with elevated privileges.
The suPHP application adds to security, while lets users run their own scripts using their low-privileged account instead of a high-privilege system account. It allows file owners to execute and edit their files so that a hacker can only access specific files on a server rather than all files owned by a single user account.
Some programs require certain folders to have 777 permissions, but it leaves the directory open to the entire world. Using 777 permissions on folders leaves them readable, writable, and executable for all users. The suPHP application does not require 777 permissions, so administrators can harden security on directories without affecting applications.
Bind MySQLd to 127.0.0.1 (Localhost)
Allowing remote connections to the MySQL database is convenient for users, but it adds a security risk to the environment. Binding MySQL to only the localhost IP (127.0.0.1) limits the attack surface, restricting only the localhost from connecting. If the database server is separated from the web host server, you can still whitelist remote connections to stop attackers from executing arbitrary commands on the MySQL server.
To bind a specific IP address to your MySQL database, you must edit the /etc/my.cnf file. After changing this file, you must restart the MySQL service. Only make these changes when you can take the database services offline for a short period of time.
In the /etc/my.cnf file, change the mysqld section to the following:
[mysqld]
bind-address = 127.0.0.1
Add Apache mod_security
Apache has a module available for free called Modsec or mod_security that adds a web application firewall (WAF) to the hosting service. A WAF blocks specific HTTP attacks such as SQL injection, Cross-Site Scripting (XSS), malicious uploads, scripted and botted exploit attempts, session hijacking and much more. For web hosters, adding mod_security to Apache reduces many threats that could harm customer sites.
Note: Before installing mod_security, ensure that it’s fully tested. If mod_security is not set up properly, it can lead to broken home pages and other parts of the website.
Force DirectAdmin to Use Newer SSL/TLS Versions
Older versions of SSL are cryptographically insecure and should not be used for any connections that transmit sensitive data. Requiring certain TLS versions is also required by some compliance regulations. For example, PCI-DSS compliance requires servers to use at least TLS 1.2. TLS 1.3 and 2.0 are also available, but server administrators often support older encryption cipher versions to ensure that users on every browser can connect to the server. If the user’s browser does not support TLS 2.0, for example, they will not be able to connect to a server that only allows TLS 2.0.
Configuring the hosting server to support SSL/TLS versions depends on the application. Luckily, Mozilla has an SSL configuration generator that will help you determine the configurations for your web server. For example, this is the configuration necessary for Apache server version 2.4.41 and OpenSSL 1.1.1d.
Block Apache Users from Executing Perl Scripts
Scripts in any programming language should be configured so that only the intended user can execute them. Perl scripts might be necessary for site owners who upload and use them, but they should not be available to the “apache” group.
To harden security, the administrator should lock down scripts and block the apache group from running them. The apache group is used by the web server to respond to HTTP/S requests, so securing this group blocks internet users from executing Perl scripts.
DirectAdmin has a quick way to do this:
chgrp apache /usr/bin/perl /usr/bin/wget /usr/local/bin/wget /usr/local/bin/curl /usr/bin/curl /usr/bin/python
chmod 705 /usr/bin/perl /usr/bin/wget /usr/local/bin/wget /usr/local/bin/curl /usr/bin/curl /usr/bin/python
What the above command does is block the apache group from reading, writing and executing any scripts within the listed directories.
Note 2: Do not block the apache group from running /usr/bin/perl if you are using mod_ruid2.
Disable Direct Access to SSH for the root User
Once attackers find the server, they would typically attempt to brute force the root user to gain access to a remote SSH session. Phishing and social engineering are also used to trick administrators into divulging server credentials. To add a layer of security to SSH, administrators can disable root and admin users from remotely creating an SSH session.
You can disable root user authentication in SSH by editing the /etc/ssh/sshd_config file and changing the PermitRootLogin configuration to:
PermitRootLogin no
After disabling remote connections for these two accounts, you still need a way to connect to the server. After you add an admin user to the server, you then edit the /etc/ssh/sshd_config file to allow the new user to access SSH by adding the following line replacing <username> with the new admin account:
AllowUsers <username>
Turn On Brute-Force Detection
DirectAdmin has a brute-force detection and monitoring feature that can be turned on to help stop attacks. Older DirectAdmin versions only support port 2222 and block based on the attacker’s IP. Newer DirectAdmin versions parse system logs and ban IPs based on repeated requests.
For older versions of DirectAdmin, turn on brute-force features using:
Admin Level -> Admin Settings -> Blacklist IPs for excessive login attempts
For newer versions of DirectAdmin, go to:
Admin Level -> Admin Settings -> Parse service logs for brute force attacks
Attacks on the server will be logged and reported in newer versions of DirectAdmin and alerts will be sen to administrators, when an ongoing attack is detected.
Use Secure Email Connections
User accounts, especially email accounts, are a favorite target for attackers. If attackers can gain access to user email accounts, they can send spam messages and masquerade as a real user on the domain. For a hoster, allowing an email server to be used for spam messages could result in it being added to spam lists. When a hoster’s email server is added to a blacklist, all emails sent from the server’s IP address will be blocked. Being blacklisted will not likely happen after only a few spam messages, but attackers use stolen email accounts to send massive amounts of spam that eventually trigger detection algorithms.
Being blacklisted for email spam can destroy a hoster's reputation. Legitimate email messages won’t be delivered to recipients, and some customers will abandon the hoster for a service that has reliable email service. Removing an email server from a spam list takes time, and large services with millions of users will often be difficult to communicate with. For example, Gmail servers pick up on spam messages and could blacklist a hoster’s email server IP. The hoster’s customers would no longer be able to send messages to Gmail users, which could make up a large portion of a site owner’s customer base. This issue is unacceptable to business owners, and it would force them to move to another hosting service.
To avoid becoming a target for spammers, the hoster can take several steps to harden email security and limit attacker abilities to compromise email accounts.
Disable UserDir Access
When a hoster creates a new account for a new user domain, Apache creates a URL with the IP and username where the customer can access their content. The URL looks like where “serverip” is the public IP for the server:
https://serverip/~username
This URL poses a security risk by exposing usernames. A threat actor can enumerate a list of usernames for a potential brute-force attack. To harden security on Apache, administrators disable this directory, which can be done using CustomBuild included with current versions of DirectAdmin. Use the following command to disable the user directory:
cd /usr/local/directadmin/custombuild
./build set userdir_access no
./build rewrite_confs
Install Anti-Malware Extensions
Website owners are often unaware of the numerous ways attackers can compromise their accounts and the web server. Installing a Linux malware scanner will greatly reduce risk of a compromise. In addition to monitoring and scanning, a Linux server antivirus extension added to the aforementioned DirectAdmin security hardening best practices will help server administrators and site owners stop common attacks.
Using anti-malware extensions, site owners and administrators can get better protection against exploits, even if they implement security best practices. Anti-malware will notify administrators and stop exploits before they can be used against the server. It’s extra protection that solves many common security issues and saves administrators time. Instead of manually remediating site owner issues, anti-malware monitors and scanners will find issues and automatically remediate them.
Take your web hosting security to the next level with Imunify360 security suite. Imunify360 is a complete security suite with all components working together to keep your servers safe and running while you could focus on other business tasks. Imunify360 is a synergy of Antivirus, Firewall, WAF, PHP Security Layer, Patch Management, Domain Reputation with easy UI and advanced automation. Try Imunify360 free for 14 days and see results in just one week.
Recommended articles:
-
- 17 ways to improve your cPanel security
- WordPress Security Ultimate Guide for 2021
- What are Antivirus False Positives and What to Do About Them?
- ModSecurity Rules: How to Guide
- Shared Hosting Security Guide for 2021
- 15 security tips for Linux VPS Hosting
- Security made easy with Imunify360
- Top 15 Plesk Server Security Best Practices to Protect Your Website
- Top 10 Web Hosting Security Best Practices
- What Are Your First Three Steps When Securing a Linux Server?
- What are steps to secure a Linux server?
- How to keep your website secure in 2021
- Ultimate Guide for DirectAdmin Security from Security Experts
.png?width=115&height=115&name=pci-dss%20(1).png "pci-dss")
