WonderShaper – A Tool to Limit Network Bandwidth in Linux

WonderShaper – A Tool to Limit Network Bandwidth in Linux

ondershaper is a small bash script that enables you to limit the network bandwidth in Linux. It employs the tc command line program as the backend for configuring traffic control. It is a handy tool for controlling bandwidth on a Linux server.

It allows you to set the maximum download rate and/or maximum upload rate. In addition, it also allows you to clear the limits that you have set and can display the current status of an interface from the command line. Instead of using the CLI options, you can run it persistently as a service under systemd.

In this article, we will show how to install and use wondershaper for limiting network bandwidth on Linux systems.

How to Install Wondershaper in Linux Systems

First, start by installing wondershaper using your Linux distribution package manager from the default repertoires as shown.

$ sudo apt install wondershaper  [On Debian/Ubuntu]
$ sudo yum install wondershaper  [On CentOS/RHEL]
$ sudo dnf install wondershaper  [On Fedora 22+]

Alternatively, to pull and install the latest updates, you need to clone the GitHub repository of wondershaper to your system, move into the local repository and install it using the following commands. Note that you should have the git command line tool installed:

$ cd bin
$ git clone https://github.com/magnific0/wondershaper.git
$ cd wondershaper
$ sudo make install

Before you start using wondershaper, you should first of all check all network interfaces attached to your machine using ifconfig or ip command.

This will help you know the interface on which you want to shape bandwidth usage, for example the wireless interface wlp1s0which is active.

$ ifconfig 
$ ip addr

How to Use Wondershaper to Limit Network Bandwidth in Linux

To define the maximum download rate in Kbps for an interface, run the following command using the option -a (defines interface) and -d (defines Kbps) i.e the download rate will be set to 4Mbps.

$ wondershaper -a wlp1s0 -d 4048

To set the maximum upload rate in Kbps for an interface, use the -u option as follows.

$ wondershaper -a wlp1s0 -u 1048

You can also set download and upload at once with a single command, for instance.

$ wondershaper -a wlp1s0 -d 4048 -u 1048

The -s option allows you to view the current status of an interface.

$ wondershaper -sa wlp1s0

You can also use iPerf – network throughput tool to test the bandwidth reduction by wondershaper, for example.

You can clear the download or upload limits you have set for an interface using the -c flag.

$ wondershaper -ca wlp1s0

It is also possible to run wondershaper as a service, where you define the parameters for shaping bandwidth in a config file. This enables wondershaper to start at boot time and limit bandwidth usage at all times, when the system is on, as explained in the next section.

How to Run Wondershaper Persistently Under Systemd

Under this mode, you need to set the interface, upload and download rates in the wondershaper configuration file located at /etc/conf.d/wondershaper. You can open this file for editing using your favorite CLI editor as shown.

$ sudo vim /etc/conf.d/wondershaper 

Define the necessary parameters as follows.

# Adapter

# Download rate in Kbps

# Upload rate in Kbps

Save the file and close it.

Next, start the wondershaper service for the mean time, enable it to auto-start at system boot and view its status, using the systemctl command.

$ sudo systemctl start wondershaper
$ sudo systemctl enable wondershaper
$ sudo systemctl status wondershaper

In case you alter the values of the parameters in the config file, you need to restart the wonderservice for the changes to be effected.

$ sudo systemctl restart wondershaper

To stop the wondershaper service, use the following command.

$ sudo systemctl stop wondershaper

For more help, see the Wondershaper Github repository: https://github.com/magnific0/wondershaper

Wondershaper is a traffic shaper for limiting network bandwidth on Linux systems. Try it out and share your thoughts with us via the feedback form below. If you know of any similar tools out there, you can as well mention to us in the comments – we will be grateful.

CSF Error: *WARNING* URLGET set to use LWP but perl module is not installed, reverting to HTTP::Tiny

You can see the issue below when installing the ConfigServer Security Firewall (csf) or restarting CSF.. *WARNING* URLGET set to use LWP but Perl module is not installed, reverting to HTTP:: Tiny


*WARNING* URLGET set to use LWP but Perl module is not installed, reverting to HTTP::Tiny


If you do, don’t worry, it’s just that you’re missing few Perl modules that CSF needs to operate properly. To solve this issue,

please install the following packages:

yum install perl-libwww-perl net-tools perl-LWP-Protocol-https -y

Or, if you’re running Ubuntu, Debian or another apt-based Linux distro, try the following:

apt-get install libwww-perl -y

Ubuntu users may also need to install ‘ sendmail ‘ and ‘ unzip ‘ while you’re at it, so check that you have those too. You should be able to restart CSF once this is achieved without seeing the error message above. Well done! ?



Please add your suggestion and feedback in below comment box

How To Secure A Linux (CentOS) Server Using CSF (ConfigServer Security And Firewall)

How To Secure A Linux (CentOS) Server Using CSF (ConfigServer Security And Firewall)

What Is Configserver Security And Firewall (CSF)

Configserver Security and Firewall is the most commonly used advanced firewall in Linux servers. It is used for Login/Intrusion detection, SSH login notification, Excessive connection blocking, Suspicious file reporting etc.

In this tutorial, we will go through the installation of CSF in Linux Server (CentOS) and also the basic and most important configuration options in CSF configuration.

Installing & Configuring CSF

CSF provides installaion script with which we can install the CSF package in a single execution of the script. We just have to download the installation script and install it.

Here are the steps for installing CSF:

#Change working directory to the desired installation directory

cd /usr/local/src

#Remove the existing package archive

rm -fv csf.tgz

#Download the package which contains the install script

wget https://download.configserver.com/csf.tgz

#Extract the archive

tar -xzf csf.tgz

#Change working directory to the CSF directory which contains the installation script

cd csf

#Execute the installation script

sh install.sh

This will install CSF in the server and you can allow/deny IPs, ports etc with ‘csf’ command. There are many other options as well and we will see that later as we progress.

To test if CSF will work in the server can be found by running,

perl /usr/local/csf/bin/csftest.pl

You can refer the screenshot given below to see the output if all the required IPtables modules are present in the server


Please note that you need to have perl installed in the server for executing this script and if it is not installed in the server you can install it by,

yum install perl

If there are any FATAL errors reported, this installation is not going to work, so you need to have the errors fixed.

Also make sure there are no other IPTABLES firewall configuration script installed. If you have installed APF + BFD previously, you can remove them by running the script given below.

sh /usr/local/csf/bin/remove_apf_bfd.sh

Now CSF is installed but by default CSF is installed in ‘Testing’ mode, to change this you need to make the following change in the CSF configuration file.

vi /etc/csf/csf.conf

Edit the calue as shown below.


You can restart csf service with,

csf -r


/etc/init.d/csf restart

With this CSF will be active and running. We can now move to the basic security settings in CSF configuration file (/etc/csf/csf.conf).

Allowing TCP and UDP Incoming and Outgoing Ports

Since attackers often exploit the open ports in the server, it is advised to only keep the necessary ports open and denying access to all the the other ports. This can be done by allowing the necesary and commonly used TCP and UDP ports in the CSF configuration file. All the other ports will be closed and attempts to acess the unallowed ports will be blocked by CSF.

Below given is the section in the configuration file where you can allow the incoming and outgoing TCP and UDP ports.

# Allow incoming TCP ports

TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995"


# Allow outgoing TCP ports

TCP_OUT = "20,21,22,25,53,80,110,113,443,587,993,995"

# Allow incoming UDP ports

UDP_IN = "20,21,53"

# Allow outgoing UDP ports

UDP_OUT = "20,21,53,113,123"

Port Flood Protection

This is used to protect the server from port flood attacks, i.e, flooding the common ports with huge number of connections and thereby denying or hanging up the services listening to those ports.

With this option, we can set the maximum number of connections a port can connect to and the new connections after this limit will be blocked by the firewall. Syntax of PORTFLOOD field is as given below.

PORTFLOOD = “port;protocol;hit_count;interval_in_seconds”

You can add multiple ports separated by commas.

Here is an example for enabling port flood protection.

PORTFLOOD = “80;tcp;50;10”

This means that if the number of connections to port 80 exceeds 50 in ten seconds, all the new connections will be blocked.

Connection Limit Protection

This option allows us to set maximum number of concurrent connections to a particular open port in the server from a single IP. This is intended for protection from denial of service attacks like DoS.


CONNLIMIT = “port;limit”

We can set connection limits for multiple ports separated by comma. Here is an example:

CONNLIMIT = "80;10,21;2"

This means, the maximum concurrent connections to port 80 (HTTP) from a single IP is 10 and to port 21 (FTP) per IP is 2.

Connection Tracking

This option allows us to set maximum number of all connections from a single IP addresses to the server. If the total number of connections from thet IP address is greater than the set value then the offending IP address is blocked. This also provides protection against denial of service attacks like Dos attacks.

Here are the examples of CT options in the configuration.

CT_LIMIT = “100”

All IPs with more than 200 connections will be blocked.


IPs with excess connection limit will blocked permanenty

CT_BLOCK_TIME = “3600”

This is to set the time period of the IP block for excessive connection limit. Above setting will block th eIP with excess connections for 3600 seconds or 1 hour.


This value sets the interval in seconds between the Connection Tracking scans and in the above example the scans will take place with 60 seconds.

These are the basic security settings. There are lot of advanced options like,

PACKET_FILTER – To drop invaid packets.

SYNFLOOD – To drop tcp SYN packet DOS attempts(Recommended only if you are under DoS attack)

ICMP_IN and ICMP_OUT – To Allow/Deny incoming and outgoing ping (ICMP) packets.

Syslog and RESTRICT_SYSLOG – To enable logging login failures to syslog and rsyslog, etc.

Useful csf command options

Block an IP with CSF

csf -d < IP Address >

Allow an IP with CSF

csf -a < IP Address >

Unblock an IP with CSF

csf -dr < IP Address >

Unblock a temporarily blocked IP with CSF

csf -tr < IP Address >

Replace <IP Address > with the actual IP Address of the user connecting to the server.

csf -s – Start firewall rules

csf -f – Flush/stop firewall rules

csf -r – Restart firewall rules

csf -x – Disable CSF

csf -e – Enable CSF

csf -c – Check for updates

csf -h – Show help screen

So there you have it. A step by step guide to to allow you to install and configure CSF in a Dedicated Server or Linux VPS.

cloudlinux csf Check for DNS recursion restrictions

Check for DNS recursion restrictions

About the recursion, I would just edit your own /etc/named.conf file and add this line:

allow-recursion { localnets; };

Somewhere in the

options {


It might look like this then:

Don’t forget to restart named.

For exim, edit your /etc/exim.conf and look under log_selector.
It should contain these settings:

Most are already present in your exim.conf, just add the ones that are missing.

After that, restart exim.

Mostly if you click on the notices CSF gives you, it will show you the solution how to fix it.

csf CloudLinux Disable ptrace error tips

Ptrace block

Starting with kernel 3.10.0-427.18.s2.lve1.4.21 ( CloudLinux 7) and 2.6.32-673.26.1.lve1.4.17 ( CloudLinux 6) we re-implemented ptrace block to protect against ptrace family of vulnerabilities. It prevents end user from using any ptrace related functionality, including such commands as strace, lsof or gdb .

By default, CloudLinux doesn’t prevent ptrace functionality.


kernel.user_ptrace = 1
kernel.user_ptrace_self = 1

The option kernel.user_ptrace disables PTRACE_ATTACH functionality, option kernel.user_ptrace_self disables PTRACE_TRACEME .

To disable all ptrace functionality change both sysctl options to 0, add this section to /etc/sysctl.conf :

## CL. Disable ptrace for users
kernel.user_ptrace = 0
kernel.user_ptrace_self = 0

Apply changes with:

$ sysctl -p
How to Establish a GRE Tunnel Between Two CentOS 7 Servers

How to Establish a GRE Tunnel Between Two CentOS 7 Servers


What is GRE? What are some advantages?

GRE stands for Generic Routing Encapsulation, which allows two servers to communicate privately. GRE tunnels are useful as they allow all types of traffic to go through. It is relatively easy to set up and is secure (imagine having a direct pipe between server A and server B).

Simply put: creating a GRE tunnel allows for packets to be forwarded with minimal resource usage.

NOTE: GRE tunnels must be set up on two endpoints.

How does it work?

When you create a GRE tunnel on your server, your server will act as a virtual router. Keep in mind that both ends will need a public IP address as packets are sent over multiple networks.

Prerequisites and Configuring Both Endpoints

What you’ll need to set a GRE tunnel up

Fortunately, all you’ll need is:

  • 2 servers running CentOS 7
  • The ip_gre module loaded
  • nano or any text editor

If you don’t already have the GRE module loaded into either server, perform the following command:

modprobe ip_gre

In order to make things easier to understand, the first and second endpoint will be labelled as A and B respectively.

The IP addresses that we’ll be using are below:

Endpoint A:

  • local/internal IP:
  • public IP:

Endpoint B:

  • local/internal IP:
  • public IP:

Keep in mind that you’ll need to modify the example IP addresses (change and with the IP addresses of the two servers that you will be using).

Configuring Endpoint A

To begin, we need to head over to the network-scripts folder:

cd /etc/sysconfig/network-scripts

Now, use nano or your favourite text editor to create a file called ifcfg-tun0:

nano ifcfg-tun0

In the newly created file, paste the following:


Save and exit (with nano, do CTRL + X, followed by ENTER).

Bring the interface up:

ifup tun0

Once you perform the command above, you can begin configuring the second endpoint.

Configuring Endpoint B

The process of configuring this endpoint is similar to that of the first one. To begin, head over to your network-scripts folder:

cd /etc/sysconfig/network-scripts

Now, create a new file called ifcfg-tun0:

nano ifcfg-tun0 

Paste the following:


Exit and save.

You can now bring the interface up:

ifup tun0

Testing the tunnels

On Endpoint A, enter the following:


You will see a similar output:

On Endpoint B:


You will see a similar output:

If both ends can ping each other successfully, you can skip to the final section of this article. If it times out, you may need to disable your firewall or whitelist the appropate addresses.

Refer to this article if you don’t understand how to create these rules.

If you only wish to test if the tunnels work, you can (at your own risk) disable the firewall on both servers:

service firewalld stop

Some CentOS 7 systems have IPTables, so perform the following if the command above does not work:

service iptables stop


You’ve successfully established a GRE tunnel between two servers. Should you wish to remove the tunnels in the future, perform the following on both servers:

ifdown tun0
rm -rf /etc/sysconfig/network-scripts/ifcfg-tun0
service network restart

Want to contribute ?

Vestacp fails to start after server restart, system enters read-only mode

Vestacp fails to start after server restart, system enters read-only mode

When the server is restarted, vestacp does not start properly.

Error Tips:

[[email protected] vesta]# systemctl status vesta.service

● vesta.service - SYSV: Run vesta web server
Loaded: loaded (/etc/rc.d/init.d/vesta; bad; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2019-11-01 09:31:19 EDT; 2min 55s ago
Docs: man:systemd-sysv-generator(8)
Process: 6018 ExecStart=/etc/rc.d/init.d/vesta start (code=exited, status=1/FAILURE)

Nov 01 09:31:19 vestacp.xen.tn systemd[1]: Starting SYSV: Run vesta web server...
Nov 01 09:31:19 vestacp.xen.tn vesta[6018]: Starting vesta-nginx: nginx: [alert] could not open error log file: open() "/usr/local/vesta/nginx/logs/error.log" failed (30: Read-only file system)
Nov 01 09:31:19 vestacp.xen.tn vesta[6018]: 2019/11/01 09:31:19 [emerg] 6024#0: open() "/usr/local/vesta/log/nginx-error.log" failed (30: Read-only file system)
Nov 01 09:31:19 vestacp.xen.tn vesta[6018]: [FAILED]
Nov 01 09:31:19 vestacp.xen.tn systemd[1]: vesta.service: control process exited, code=exited status=1
Nov 01 09:31:19 vestacp.xen.tn systemd[1]: Failed to start SYSV: Run vesta web server.
Nov 01 09:31:19 vestacp.xen.tn systemd[1]: Unit vesta.service entered failed state.
Nov 01 09:31:19 vestacp.xen.tn systemd[1]: vesta.service failed.

The correct way:

sudo mount -o remount,rw /dev/vda1 /

/dev/vda1 Need to change to the drive letter used by your current system, we can query by the command “df -h”

Now we restart vestacp and we will see that the panel has run successfully.

systemctl restart vesta