Coders Tent

Server Admin's Diary

Category: VPS Security

How to Prevent Annoying Spam Outbreaks in cPanel and Plesk Servers

Reader Score
[Total: 0 Average: 0]

Spam is not just annoying, but often a security threat. Cleaning up cluttered mailboxes is time-consuming and messages are often laced with virus attachments or malicious links.

The best webmasters prevent spam, not just clean it up!

1. How to Prevent Spam in cPanel and Plesk

Use SpamAssassin + spam filter

Both cPanel and Plesk have SpamAssassin (SA) preinstalled and integrated into the local mail server. When enabled, SA scans all incoming email and rates them on various factors.

For example, does the email have images and no text?

If the rating exceeds the allowed score, the email is marked as spam or deleted (as based on your preferences).

Both panels also offer other filters, allow you to redirect or even delete emails based on keywords.

For example, the word “Viagra” in the subject line. These filters, in combination with SpamAssassin detections, create a very powerful anti-spam mechanism on the server.

How to enable SA in cPanel

  1. Login to cPanel, go to the mail section.
  2. Click the SpamAssassin icon and then enable it.
  3. Note the options to auto-delete mail, or auto-add a prefix to suspect messages.
  4. Using either the Global Mail Filters or the Mail Filters, add keyword-based filtering as needed.

How to enable SA in Plesk

  1. Login to Plesk
  2. Go to your domain
  3. Go to the Mail tab
  4. Go to the email address that you want to filter
  5. Enable SpamAssassin (and as with cPanel, note the options to mark or delete)

2. Enable DKIM and SPF checks

DKIM is the second revision of the DomainKeys authentication system. It checks whether an email is from the domain it claims to have been sent from.

If the message fails this check, it gets rejected by the server as spam.

DKIM is two-way. Any email you send must be signed in order to not be discarded or bounced by another server. And then you can instruct your server to reject or black hole as well.

This process involves many steps, and a great guide for these panels can be found  here. Plesk has a dedicated DKIM selection area, while cPanel leverages DKIM checking via custom SpamAssassin mail filtering rules.

3. Disable catchall email

The catch-all (or catchall), aka the domain default email account, will accept all messages to non-existent accounts on a server when enabled.

Spammers blast spam to sites, whether or not they know an address.

For example, [email protected] is a common spam message sent to all sites. If [email protected] does not exist, and a catchall does, it’s diverted to this mailbox. So never enable the catchall address!

Doing so wastes server space, can consume CPU and RAM, and can allow malware onto the system.

While it can be useful for senders who mistyped the email address, it’s not worth it. Either set the address to either blackhole (discard) or reject (bounce) the messages.

To enable in cPanel

  1. Login to cPanel
  2. Click the Default Address icon
  3. Discard under the advanced options
  4. Ignore the cPanel warning that it’s not recommended. It most certainly is recommended! Note that bouncing can create a backscatter problem, so blackholing is the best option.

To enable in Plesk

  1. Login to Plesk
  2. Go to your domain
  3. Go to the Mail tab
  4. Click on Mail for Non-Existent Users
  5. Make sure “reject” is enabled by default. (Unfortunately, Plesk does not give the option to blackhole, so reject is next best)

Source :

EuroVPS Article.

20 Ways to Secure Your Linux VPS so You Don’t Get Hacked

Reader Score
[Total: 0 Average: 0]

Linux VPS servers have their advantages. In fact, Linux VPS are much more secure when compared to other operating systems like Windows because of Linux’s security model (LSM). But they’re not perfect, and definitely not invulnerable. In this post we’ll go over 20 ways you can secure your VPS and protect it from hackers.

Linux’s default security is pretty good, and better than that of most of its competitors, but it still has weaknesses.

These techniques don’t need to take a huge amount of time and effort, but a certain level of administrative experience is required.

If you need any help then don’t be afraid to get in touch – we’ll be happy to help.

Let’s get started, here are 20 ways to keep your VPS secure.

1. Disable root logins

Want a secure VPS? Then you should never log in as the root user.

By default, every Linux VPS has “root” as a username, and so hackers try brute force attacks to crack the password and gain access. Disabling logins from the “root” username adds another layer of security, as it stops hackers from simply guessing your user credentials.

Instead of logging in as the root user, you’ll need to create another username and use the “sudo” command to execute root level commands.

Sudo is a special access right that can be given to authorized users so that they can run administrative commands, and it eliminates the need for root access.

Be sure to create your non-root user and to give it the appropriate levels of authorization before you disable the “root” account.

When you’re ready, go ahead by opening up /etc/ssh/sshd_config in nano or vi and finding the “PermitRootLogin” parameter.

By default, this will say “yes”.

Change it to “no” and save the changes.

2. Change the SSH port

It’s hard for people to hack SSH when they can’t find it. Changing the SSH port number can prevent malicious scripts from directly connecting to the default port (22).

To do this, you’ll need to open up /etc/ssh/sshd_config and to change the appropriate setting.

Be sure to double check whether the chosen port number is being used by any other services – you don’t want to create a clash!

3. Keep server software updated

It isn’t difficult to update your server’s software.

You can simply use the rpm/yum package manager (CentOS/RHEL) or apt-get (Ubuntu/ Debian) to upgrade to newer versions of installed software, modules, and components.

You can even configure the operating system to send yum package update notifications via email. This makes it easy to keep track of what’s changing. And, if you’re happy to automate the task, you can set up a cronjob to apply all available security updates on your behalf.

If you’re using a panel, such as Plesk or cPanel, then you’ll need to update that, too. Most panels can be set to update themselves automatically, and cPanel uses EasyApache for most package updates.

Finally, you’ll want to apply security patches as quickly as possible. The longer you wait, the more likely you are to succumb to a malicious attack.

4. Disable unused network ports

Open network ports and unused network services are easy targets for hackers, and you’ll want to protect yourself against exploitation.

Use the “netstat” command to see all currently open network ports and their associated services.

Consider setting up “iptables” to close all open ports or using the “chkconfig” command to disable unwanted services. And if you use a firewall like CSF, you can even automate the iptables rules.

5. Remove unwanted modules/packages

It’s unlikely that you’ll need all of the packages and services that came bundled with your Linux distribution. Every service that you remove is one less weakness to worry about, so make sure that you’re only running services that you’re actually using.

On top of that, avoid installing unnecessary software, packages, and services to minimize potential threats. It has the welcome side-effect of streamlining your server’s performance, too!

6. Disable IPv6

IPv6 has several advantages over IPv4, but it’s unlikely that you’re using it – few people are.

Not using IPv6? Disable it!

But it is used by hackers, who often send malicious traffic via IPv6, and leaving the protocol open can expose you to potential exploits. To combat the problem, edit /etc/sysconfig/ network and update the settings so that they read NETWORKING_ IPV6=no and IPV6INIT=no.

7. Use GnuPG encryption

Hackers often target data while it’s in transit over a network. That’s why it’s vital to encrypt transmissions to your server using passwords, keys and certificates. One popular tool is GnuPG, a key-based authentication system that’s used to encrypt communications. It uses a “public key” that can only be decrypted by a “private key” that’s available only to the intended recipient.

8. Have a strong password policy

Weak passwords always have been – and always will be – one of the largest threats to security. Don’t allow user accounts to have empty password fields, or to use simple passwords like “123456”, “password”, “qwerty123” or “trustno1”.

You can boost security by requiring all passwords to mix lower and upper case, to avoid the use of dictionary words and to include numbers and symbols. Enable password aging to force users to change old passwords at regular intervals, and consider restricting the re-use of previous passwords.

Also use the “faillog” command to set a login failure limit and to lock user accounts after repeated failed attempts to protect your system from brute force attacks.

9. Configure a firewall

Simply put, you need a firewall if you want a truly secure VPS.

Luckily, there are plenty to choose from. NetFilter is a firewall that comes integrated with the Linux kernel, and you can configure it to filter out unwanted traffic. With the help of NetFilter and iptables, you can fight against distributed denial of service (DDos) attacks.

TCPWrapper is another useful application, a host-based access control list (ACL) system that’s used to filter network access for different programs. It offers host name verification, standardized logging and spoofing protection, all of which can help to beef up your security.

Other popular firewalls include CSF and APF, both of which offer plugins for popular panels like cPanel and Plesk.

10. Use disk partitioning

For added security, it’s a good idea to partition your disk to keep operating system files away from user files, tmp files and third-party programs. You can also disable SUID/SGID access (nosuid) and disable the execution of binaries (noexec) on the operating system partition.

11. Make /boot read-only

On Linux servers, all kernel-specific files are stored inside the “/boot” directory.

But the default access level for the directory is “read-write”. To prevent unauthorized modification of the boot files – which are critical to the smooth running of your server – then it’s a good idea to change the access level to “read only”.

To do this, simply edit the /etc/fstab file and add LABEL=/boot /boot ext2 defaults, ro 1 2 to the bottom. And, if you need to make changes to the kernel in the future, you can simply revert back to “read-write” mode. Then you can make your changes and set it back to “read only” when you’ve finished.

12. Use SFTP, not FTP

File transfer protocol (FTP) is outdated and no longer safe, even when using “FTP over TLS” (FTPS) encrypted connections.

Both FTP and FTPS are still vulnerable to packet sniffing, when a computer program intercepts and logs the traffic that’s passing over your network. FTP is fully “in the clear” and FTPS file transfers are also “in the clear”, which means that only the credentials are encrypted.

SFTP is “FTP over SSH” (also known as “secure FTP”), and it fully encrypts all data – including both the credentials and the files that are being transferred.

13. Use a firewall

Your firewall is the gatekeeper that either allows or denies access to the server, and it’s your first line of defense against hackers.

Installing and configuring a firewall should be one of the first things that you do when setting up and securing a VPS or bare metal server.

Check here Installing and configuring ConfigServer Security & Firewall (CSF) Tutorial

14. Install antimalware/antivirus software

A firewall’s main job is to deny access to any sources of known malicious traffic, and it effectively acts as your first line of defense. But no firewall is fool-proof and harmful software can still slip through, which is why you need to protect yourself further.

Too many novice server admins fail to install anti-malware software, and that’s a mistake. The most common reason for this isn’t laziness – it’s actually because they don’t want to spend money on security software.

As a rule, the paid solutions are usually the best, because their revenue stream allows them to hire talented programmers and researchers who can help the software to stay relevant.

But if budget is an option then it’s a good idea to look at some of the free alternatives.

ClamAV and Maldet are two open-source applications that can scan your server and score potential threats. That’s why we install both of them as part of the VPS security hardening process for our managed hosting customers.

Check here How to Install and Configure Linux Malware Detect (LMD) Tutorial

15. Turn on CMS auto-updates

Hackers are constantly trying to locate security loopholes – especially in your website’s content management system (CMS). Popular CMS providers include Joomla, Drupal and WordPress, which powers nearly 20% of the web.

Most CMS developers regularly release security fixes, as well as new features.

Much more allow you to automatically update the CMS so that the fix is applied as soon as a new version is released. WordPress was late to the game with auto-updates, and if you’re running an older site then it might be disabled by default. Be sure to check the setting and to enable auto-updates where possible.

Remember that your website’s content is your responsibility, and not your host’s. It falls to you to ensure that it’s regularly updated, and it’s a good idea to take regular backups, too.

16. Enable cPHulk in WHM

As well as offering a firewall, cPanel also has “cPHulk” brute force protection.

Firewalls aren’t infallible, and “good” traffic that slips through can turn out to be bad. These false positives are due to the firewall’s settings, and tweaks might be needed to offer additional protection.

In the meantime, cPHulk acts like a secondary firewall, preventing brute-force attacks (from repeated attempts to guess the password) on the server.

We often find that cPHulk blocks the login ability first and that the firewall later catches up, banning the entire IP. To enable it, you’ll need to go to the WHM Security Center and select cPHulk Brute Force Protection. This is another step in the security hardening process that we use on our managed VPS and dedicated servers.

17. Prevent anonymous FTP uploads

cPanel and Plesk both disable anonymous FTP uploads by default but other setups can come with it pre-enabled.

Allowing anonymous users to upload via FTP is a massive security risk, because it allows anyone to upload anything they want to your web server. As you can imagine, it’s not recommended – it’s a bit like giving your keys to a burglar.

To disable anonymous uploads, edit your server’s FTP configuration settings.

18. Install a rootkit scanner

One of the most dangerous pieces of malware is the rootkit.

It exists at the operating system (OS) level, below other normal security software, and it can allow undetected access to a server. Luckily, you can use “chrootkit”, an open-source tool, to find out whether your server is infected. But rootkits aren’t always easy to remove, and the best way to fix the issue is often to reinstall the OS.

19. Take regular backups

Too many people forget to take regular backups – and then they regret it when something goes wrong and they don’t have a copy of their data. No matter how careful you are, and no matter how secure your server is, there’s always a chance that something could go wrong.

Don’t take unnecessary risks by failing to take backups, and don’t rely on your host to do it either. Taking backups of your own is recommended, even if your hosting provider says that they do it on your behalf. Store copies of it in different locations and consider using the cloud so that your backup can be accessed from anywhere.

20. Use a strong password

We know, we know – we’ve already said this.

But a strong password policy is absolutely vital, and so it’s always worth repeating. Poor passwords are still the number one threat to security. And the same applies for when securing windows servers as well!

Password protocol is often misunderstood. Complexity is important, but so is length. While it’s a good idea to use a mixture of capital and lower case letters, numbers and special characters, you should also make it as long as is realistically possible.


Source : Internet Collection

How to Install and Configure Linux Malware Detect (LMD) on CentOS 7

Reader Score
[Total: 0 Average: 0]

Linux Malware Detect (LMD) or simply Maldet is a free malware scanner designed for Linux machines released under the GNU GPLv2. It is specially designed around the threats in the shared hosted environment. LMD uses threat data from network edge intrusion detection systems to get the actual malware that is used in attacks and generates a variety of signatures for detection.

In addition to these features, LMD threat data can also be extracted from user submissions with the checkout feature in LMD from malware resources. It uses signatures such as HEX pattern and MD5 file hashes. They can also be extracted from a variety of detection tools including ClamAV.

Before we start the installation process, this tutorial assumes that you have some basic knowledge of SSH. These instructions apply to users who deal with VPS (Virtual Private Servers) or Dedicated servers.

Let’s get started.

Step 1: Updating the Packages

First, make sure the packages are up-to-date. To do so, run the command below:


$ yum -y update

Step 2: Installing Linux Malware Detect

Go to the official Linux Malware Detect page and download the software to your server:


$ wget http://www.rfxn.com/downloads/maldetect-current.tar.gz

Open the already downloaded Linux Malware file:


$ tar xfz maldetect-current.tar.gz

You can change the current directory with the command below:


$ cd maldetect-*

Now run the file to install the script:


sh install.sh

Once the installation process is complete, you should have the output below:


Created symlink from /etc/systemd/system/multi-user.target.wants/maldet.service to /usr/lib/systemd/system/maldet.service.
Linux Malware Detect v1.6
(C) 2002-2017, R-fx Networks (C) 2017, Ryan MacDonald
This program may be freely redistributed under the terms of the GNU GPL
installation completed to /usr/local/maldetect
config file: /usr/local/maldetect/conf.maldet
exec file: /usr/local/maldetect/maldet
exec link: /usr/local/sbin/maldet
exec link: /usr/local/sbin/lmd
cron.daily: /etc/cron.daily/maldet
maldet(1344): {sigup} performing signature update check...
maldet(1344): {sigup} local signature set is version 2017070716978
maldet(1344): {sigup} new signature set (2017080720059) available
maldet(1344): {sigup} downloading https://cdn.rfxn.com/downloads/maldet-sigpack.tgz
maldet(1344): {sigup} downloading https://cdn.rfxn.com/downloads/maldet-cleanv2.tgz
maldet(1344): {sigup} verified md5sum of maldet-sigpack.tgz
maldet(1344): {sigup} unpacked and installed maldet-sigpack.tgz
maldet(1344): {sigup} verified md5sum of maldet-clean.tgz
maldet(1344): {sigup} unpacked and installed maldet-clean.tgz
maldet(1344): {sigup} signature set update completed
maldet(1344): {sigup} 15215 signatures (12485 MD5 | 1951 HEX | 779 YARA | 0 USER)

Step 3: Configuring LMD

Linux Malware Detect configuration file is /usr/local/maldetect/conf.maldet and it can be modified as per the requirements below:


$ vi /usr/local/maldetect/conf.maldet

The default file in your system should look like this:


# Enable Email Alerting
email_alert="1"
# Email Address in which you want to receive scan reports
email_addr="[email protected]"
# Use with ClamAV
scan_clamscan="1"
# Enable scanning for root owned files. Set 1 to disable.
scan_ignore_root="0"
# Move threats to quarantine
quarantine_hits="1"
# Clean string based malware injections
quarantine_clean="1"
# Suspend user if malware found.
quarantine_suspend_user="1"
# Minimum userid value that be suspended
quarantine_suspend_user_minuid="500"

Now change the settings below:

email_alert=1 – If you want to receive email alerts

email_addr=”[email protected]” – Type the address where you want to receive the malware email alerts

quar_hits=1 – The default quarantine alert for malware hits

quar_clean=1 – Clears the detected malware injections

Step 4: Set CronJob for Auto Scanning

In the installation process, a cron job file is installed in /etc/cron.daily/maldet.

These files installed by LMD are useful in keeping the current session, performing daily updates of the signature files, temp, as well as store quarantine data for not more than two weeks or 14 days. It runs a daily scan of all recent files on the system.

To ensure these files are compatible with the structure of your server and those in the Cron file, check the control panel and make the necessary changes.


#!/bin/bash
# clear quarantine/session/tmp data every 14 days
/usr/sbin/tmpwatch 336 /usr/local/maldetect/tmp >> /dev/null 2>&1
/usr/sbin/tmpwatch 336 /usr/local/maldetect/sess >> /dev/null 2>&1
/usr/sbin/tmpwatch 336 /usr/local/maldetect/quarantine >> /dev/null 2>&1
/usr/sbin/tmpwatch 336 /usr/local/maldetect/pub/*/ >> /dev/null 2>&1
# check for new release version
/usr/local/maldetect/maldet -d >> /dev/null 2>&1
# check for new definition set
/usr/local/maldetect/maldet -u >> /dev/null 2>&1
# if were running inotify monitoring, send daily hit summary
if [ "$(ps -A --user root -o "comm" | grep inotifywait)" ]; then
/usr/local/maldetect/maldet --alert-daily >> /dev/null 2>&1
else
# scan the last 2 days of file changes
if [ -d "/home/virtual" ] && [ -d "/usr/lib/opcenter" ]; then
# ensim
/usr/local/maldetect/maldet -b -r /home/virtual/?/fst/var/www/html 2 >> /dev/null 2>&1
/usr/local/maldetect/maldet -b -r /home/virtual/?/fst/home/?/public_html 2 >> /dev/null 2>&1
elif [ -d "/etc/psa" ] && [ -d "/var/lib/psa" ]; then
# psa
/usr/local/maldetect/maldet -b -r /var/www/vhosts/?/httpdocs 2 >> /dev/null 2>&1
/usr/local/maldetect/maldet -b -r /var/www/vhosts/?/subdomains/?/httpdocs 2 >> /dev/null 2>&1
elif [ -d "/usr/local/directadmin" ]; then
# DirectAdmin
/usr/local/maldetect/maldet -b -r /var/www/html/?/ 2 >> /dev/null 2>&1
/usr/local/maldetect/maldet -b -r /home?/?/domains/?/public_html 2 >> /dev/null 2>&1
else
# cpanel, interworx and other standard home/user/public_html setups
/usr/local/maldetect/maldet -b -r /home?/?/public_html 2 >> /dev/null 2>&1
fi
fi

To active the email alerts once a malware is detected, open the Maldet configuration file that is found in /usr/local/maldetect/conf.maldet and type the following:

email_alert=1
email_subj=”Maldet alert from $(hostname)”
email_addr=”[email protected]

Step 5: Manual Scanning

To scan a directory you want to use, run the command below:


$ maldet -a /path/to/directory

To ensure Maldet is up-to-date, run the command below:


$ maldet -u

You can see the details of the options available by running the following command:


$ maldet - h

Now Linux Malware Detect (LMD) is successfully installed.

Installing and configuring ConfigServer Security & Firewall (CSF)

Reader Score
[Total: 0 Average: 0]

Config Server Firewall (CSF) is a Stateful Packet Inspection (SPI) firewall, Login/Intrusion Detection and Security application for Linux servers.

It’s is a security tool that can protect your server against attacks, such as brute force, and improve server security.

This application will work as a WHM plugin and is free. Follow these instructions to complete a basic CSF installation:

1. Install CSF: Log into your server as root, using SSH.


cd /usr/local/src/
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh

You will see “Installation Completed”.


cd ..
rm -Rfv csf/ csf.tgz

2. Configure CSF: Login to your server via WHM as root and go to the bottom left menu. In the Plugins section, go to ConfigServer Security Firewall.

Then, in the “csf – ConfigServer Firewall” section (on the right panel), click on “Firewall Configuration”.

# Port filtering configuration – IPv4 Port Settings #

The following ports are opened by default:

TCP_IN =
20,21,22,25,53,80,110,143,443,465,587,993,995,
2077,2078,2082,2083,2086,2087,2095,2096,26

TCP_OUT =
20,21,22,25,37,43,53,80,110,113,443,587,873,2086,2087,2089,2703

UDP_IN =
20,21,53

UDP_OUT =
20,21,53,113,123,873,6277

If you have changed your SSH port number, you need to add this new port on the “IPv4 Port Settings” and/or “IPv6 Port Settings”.

You can also use this section to add a specific port for an new application installed on the server.

If you are using R1soft/Idera external backup solution, you need to allow inbound traffic for TCP port 1167 in the port TCP_IN section.

# Enable syslog monitoring #

Set “SYSLOG_CHECK” to “1800”

# Detect suspicious process #

Set “PT_DELETED” to “1”

Set “PT_ALL_USERS” to “1”

# Spam Protection and massive email activity detection (optional) – SMTP Settings#

CSF can help you to secure spam abuse vector and detect suspicious email activities.

Set “SMTP_BLOCK” to “1” in “SMTP Settings” section.

Set “LF_SCRIPT_LIMIT” to “250” to identify scripts sending out 250 emails messages in an hour.

Set “LF_SCRIPT_ALERT” to “1” to send an email alert to the system administrator when the limit configured above is reached.

# Save the configuration and confirm the firewall status #

You can save the configuration by clicking the “Change” button at the end of the page. Then restart csf/lfd service.

Thereafter, go back in the ConfigServer Security Firewall main page.

On the top of this page, you should see “Firewall Status: Enabled but in Test Mode”

If you see “Firewall Status: Disabled and Stopped” please click on “Enable”.

3. Confirm the configuration and remove the “Testing mode”.

Once you are satisfied with the configuration and confirmed that it is working fine, you need to remove the “Testing mode”.

Go back in the “Firewall Configuration (“csf – ConfigServer Firewall” section)

Set “TESTING” to 0

Save this modification by clicking the “Change” button at the end of the page and restart csf/lfd service.

4. Monitor the firewall activity

You can monitor the firewall activity by clicking the “Watch system Logs” button on the ConfigServer Security Firewall main page.

Or read the log file /var/log/lfd.log which is accessible via SSH.


Reference: http://www.configserver.com/cp/csf.html