How To Set Up Nginx Server Blocks (Virtual Hosts) on Ubuntu 16.04

Reference : https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04

Introduction

When using the Nginx web server, server blocks (similar to the virtual hosts in Apache) can be used to encapsulate configuration details and host more than one domain off of a single server.

In this guide, we’ll discuss how to configure server blocks in Nginx on an Ubuntu 16.04 server.

Prerequisites

We’re going to be using a non-root user with sudo privileges throughout this tutorial. If you do not have a user like this configured, you can create one by following our Ubuntu 16.04 initial server setup guide.

You will also need to have Nginx installed on your server. The following guides cover this procedure:

When you have fulfilled these requirements, you can continue on with this guide.

Example Configuration

For demonstration purposes, we’re going to set up two domains with our Nginx server. The domain names we’ll use in this guide are example.com and test.com.

You can find a guide on how to set up domain names with DigitalOcean here. If you do not have two spare domain names to play with, use dummy names for now and we’ll show you later how to configure your local computer to test your configuration.

Step One: Set Up New Document Root Directories

By default, Nginx on Ubuntu 16.04 has one server block enabled by default. It is configured to serve documents out of a directory at /var/www/html.

While this works well for a single site, we need additional directories if we’re going to serve multiple sites. We can consider the /var/www/html directory the default directory that will be served if the client request doesn’t match any of our other sites.

We will create a directory structure within /var/www for each of our sites. The actual web content will be placed in an html directory within these site-specific directories. This gives us some additional flexibility to create other directories associated with our sites as siblings to the html directory if necessary.

We need to create these directories for each of our sites. The -p flag tells mkdir to create any necessary parent directories along the way:

  • sudo mkdir -p /var/www/example.com/html
  • sudo mkdir -p /var/www/test.com/html

Now that we have our directories, we will reassign ownership of the web directories to our normal user account. This will let us write to them without sudo.

Note

Depending on your needs, you might need to adjust the permissions or ownership of the folders again to allow certain access to the www-data user. For instance, dynamic sites will often need this. The specific permissions and ownership requirements entirely depend on what your configuration. Follow the recommendations for the specific technology you’re using.

We can use the $USER environmental variable to assign ownership to the account that we are currently signed in on (make sure you’re not logged in as root). This will allow us to easily create or edit the content in this directory:

  • sudo chown -R $USER:$USER /var/www/example.com/html
  • sudo chown -R $USER:$USER /var/www/test.com/html

The permissions of our web roots should be correct already if you have not modified your umask value, but we can make sure by typing:

  • sudo chmod -R 755 /var/www

Our directory structure is now configured and we can move on.

Step Two: Create Sample Pages for Each Site

Now that we have our directory structure set up, let’s create a default page for each of our sites so that we will have something to display.

Create an index.html file in your first domain:

  • nano /var/www/example.com/html/index.html

Inside the file, we’ll create a really basic file that indicates what site we are currently accessing. It will look like this:

/var/www/example.com/html/index.html
<html>
    <head>
        <title>Welcome to Example.com!</title>
    </head>
    <body>
        <h1>Success!  The example.com server block is working!</h1>
    </body>
</html>

Save and close the file when you are finished.

Since the file for our second site is basically going to be the same, we can copy it over to our second document root like this:

  • cp /var/www/example.com/html/index.html /var/www/test.com/html/

Now, we can open the new file in our editor:

  • nano /var/www/test.com/html/index.html

Modify it so that it refers to our second domain:

/var/www/test.com/html/index.html
<html>
    <head>
        <title>Welcome to Test.com!</title>
    </head>
    <body>
        <h1>Success!  The test.com server block is working!</h1>
    </body>
</html>

Save and close this file when you are finished. We now have some pages to display to visitors of our two domains.

Step Three: Create Server Block Files for Each Domain

Now that we have the content we wish to serve, we need to actually create the server blocks that will tell Nginx how to do this.

By default, Nginx contains one server block called default which we can use as a template for our own configurations. We will begin by designing our first domain’s server block, which we will then copy over for our second domain and make the necessary modifications.

Create the First Server Block File

As mentioned above, we will create our first server block config file by copying over the default file:

  • sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/example.com

Now, open the new file you created in your text editor with sudo privileges:

  • sudo nano /etc/nginx/sites-available/example.com

Ignoring the commented lines, the file will look similar to this:

/etc/nginx/sites-available/example.com
server {
        listen 80 default_server;
        listen [::]:80 default_server;

        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                try_files $uri $uri/ =404;
        }
}

First, we need to look at the listen directives. Only one of our server blocks on the server can have the default_server option enabled. This specifies which block should serve a request if the server_namerequested does not match any of the available server blocks. This shouldn’t happen very frequently in real world scenarios since visitors will be accessing your site through your domain name.

You can choose to designate one of your sites as the “default” by including the default_server option in the listen directive, or you can leave the default server block enabled, which will serve the content of the /var/www/html directory if the requested host cannot be found.

In this guide, we’ll leave the default server block in place to server non-matching requests, so we’ll remove the default_server from this and the next server block. You can choose to add the option to whichever of your server blocks makes sense to you.

/etc/nginx/sites-available/example.com
server {
        listen 80;
        listen [::]:80;

        . . .
}
Note

You can check that the default_server option is only enabled in a single active file by typing:

  • grep -R default_server /etc/nginx/sites-enabled/

If matches are found uncommented in more than on file (shown in the leftmost column), Nginx will complain about an invalid configuration.

The next thing we’re going to have to adjust is the document root, specified by the root directive. Point it to the site’s document root that you created:

/etc/nginx/sites-available/example.com
server {
        listen 80;
        listen [::]:80;

        root /var/www/example.com/html;

}

Next, we need to modify the server_name to match requests for our first domain. We can additionally add any aliases that we want to match. We will add a http://www.example.com alias to demonstrate.

When you are finished, your file will look something like this:

/etc/nginx/sites-available/example.com
server {
        listen 80;
        listen [::]:80;

        root /var/www/example.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name example.com www.example.com;

        location / {
                try_files $uri $uri/ =404;
        }
}

That is all we need for a basic configuration. Save and close the file to exit.

Create the Second Server Block File

Now that we have our initial server block configuration, we can use that as a basis for our second file. Copy it over to create a new file:

  • sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/test.com

Open the new file with sudo privileges in your editor:

  • sudo nano /etc/nginx/sites-available/test.com

Again, make sure that you do not use the default_server option for the listen directive in this file if you’ve already used it elsewhere. Adjust the root directive to point to your second domain’s document root and adjust the server_name to match your second site’s domain name (make sure to include any aliases).

When you are finished, your file will likely look something like this:

/etc/nginx/sites-available/test.com
server {
        listen 80;
        listen [::]:80;

        root /var/www/test.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name test.com www.test.com;

        location / {
                try_files $uri $uri/ =404;
        }
}

When you are finished, save and close the file.

Step Four: Enable your Server Blocks and Restart Nginx

Now that we have our server block files, we need to enable them. We can do this by creating symbolic links from these files to the sites-enabled directory, which Nginx reads from during startup.

We can create these links by typing:

  • sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
  • sudo ln -s /etc/nginx/sites-available/test.com /etc/nginx/sites-enabled/

These files are now in the enabled directory. We now have three server blocks enabled, which are configured to respond based on their listen directive and the server_name (you can read more about how Nginx processes these directives here):

  • example.com: Will respond to requests for example.com and http://www.example.com
  • test.com: Will respond to requests for test.com and http://www.test.com
  • default: Will respond to any requests on port 80 that do not match the other two blocks.

In order to avoid a possible hash bucket memory problem that can arise from adding additional server names, we will go ahead and adjust a single value within our /etc/nginx/nginx.conf file. Open the file now:

  • sudo nano /etc/nginx/nginx.conf

Within the file, find the server_names_hash_bucket_size directive. Remove the # symbol to uncomment the line:

/etc/nginx/nginx.conf
http {
    . . .

    server_names_hash_bucket_size 64;

    . . .
}

Save and close the file when you are finished.

Next, test to make sure that there are no syntax errors in any of your Nginx files:

  • sudo nginx -t

If no problems were found, restart Nginx to enable your changes:

  • sudo systemctl restart nginx

Nginx should now be serving both of your domain names.

Step Five: Modify Your Local Hosts File for Testing(Optional)

If you have not been using domain names that you own and instead have been using dummy values, you can modify your local computer’s configuration to let you to temporarily test your Nginx server block configuration.

This will not allow other visitors to view your site correctly, but it will give you the ability to reach each site independently and test your configuration. This basically works by intercepting requests that would usually go to DNS to resolve domain names. Instead, we can set the IP addresses we want our local computer to go to when we request the domain names.

Note

Make sure you are operating on your local computer during these steps and not your VPS server. You will need to have root access, be a member of the administrative group, or otherwise be able to edit system files to do this.

If you are on a Mac or Linux computer at home, you can edit the file needed by typing:

  • sudo nano /etc/hosts

If you are on Windows, you can find instructions for altering your hosts file here.

You need to know your server’s public IP address and the domains you want to route to the server. Assuming that my server’s public IP address is 203.0.113.5, the lines I would add to my file would look something like this:

/etc/hosts
127.0.0.1   localhost
. . .

203.0.113.5 example.com www.example.com
203.0.113.5 test.com www.test.com

This will intercept any requests for example.com and test.com and send them to your server, which is what we want if we don’t actually own the domains that we are using.

Save and close the file when you are finished.

Step Six: Test your Results

Now that you are all set up, you should test that your server blocks are functioning correctly. You can do that by visiting the domains in your web browser:

http://example.com

You should see a page that looks like this:

Nginx first server block

If you visit your second domain name, you should see a slightly different site:

http://test.com

Nginx second server block

If both of these sites work, you have successfully configured two independent server blocks with Nginx.

At this point, if you adjusted your hosts file on your local computer in order to test, you’ll probably want to remove the lines you added.

If you need domain name access to your server for a public-facing site, you will probably want to purchase a domain name for each of your sites. You can learn how to set them up to point to your server here.

Conclusion

You should now have the ability to create server blocks for each domain you wish to host from the same server. There aren’t any real limits on the number of server blocks you can create, so long as your hardware can handle the traffic.

composer update –no-scripts “Killed” at live server

composer update –no-scripts
has been killed in live server

or

PHP Fatal  error: Uncaught Error: Class ‘Illuminate\Fuoundawtion\Applicationo’ not found in /var/www/server_activation/Bootstrap/app.php:14

 

that case is becasue of not enough memory in live sever. so we need to give the enough memory space to our project

sudo fallocate -l 1G /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

 

Installing Phpmyadmin at Ubuntu 14.04/16.04 with LEMP

1)  sudo apt-get install phpmyadmin

2) check where is the site
cd /usr/share/nginx/html

3) sudo ln  -s /usr/share/phpmyadmin/ /usr/share/nginx/html
it will create a new link name “phpmyadmin” under /user/share/nginx/html
if you want to create custom phpmyadmin link, you can create by the following command
sudo ln  -s /usr/share/phpmyadmin_mycustom_name/ /usr/share/nginx/html
it will create a new link name “phpmyadmin_mycustom_name” under /user/share/nginx/html
And we can call it from browser by “http://ip_address/phpmyadmin&#8221; or “http://ip_address/phpmyadmin_mycustom_name&#8221;

4) sudo systemctl restart nginx

5) if there is “root /var/www/html” at /etc/nginx/sites-available/default, comment out it
eg ” # root /var/www/html ” and change server_name to
server_name localhost / ip_address;

6) if “cgi.fix_pathinfo = 0” at /etc/php/7.0/fpm/php.ini, pls change back to original “cgi.fix_pathinfo = 1”
sudo systemctl restart nginx

UFW Essentials: Common Firewall Rules and Commands

Reference
https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands

 

Introduction

UFW is a ll configuration tool for iptables that is included with Ubuntu by default. This cheat sheet-style guide provides a quick reference to UFW commands that will create iptables firewall rules are useful in common, everyday scenarios. This includes UFW examples of allowing and blocking various services by port, network interface, and source IP address.

How To Use This Guide

  • If you are just getting started with using UFW to configure your firewall, check out our introduction to UFW
  • Most of the rules that are described here assume that you are using the default UFW ruleset. That is, it is set to allow outgoing and deny incoming traffic, through the default policies, so you have to selectively allow traffic in
  • Use whichever subsequent sections are applicable to what you are trying to achieve. Most sections are not predicated on any other, so you can use the examples below independently
  • Use the Contents menu on the right side of this page (at wide page widths) or your browser’s find function to locate the sections you need
  • Copy and paste the command-line examples given, substituting the values in red with your own values

Remember that you can check your current UFW ruleset with sudo ufw status or sudo ufw status verbose.

Block an IP Address

To block all network connections that originate from a specific IP address, 15.15.15.51 for example, run this command:

  • sudo ufw deny from 15.15.15.51

In this example, from 15.15.15.51 specifies a source IP address of “15.15.15.51”. If you wish, a subnet, such as 15.15.15.0/24, may be specified here instead. The source IP address can be specified in any firewall rule, including an allow rule.

Block Connections to a Network Interface

To block connections from a specific IP address, e.g. 15.15.15.51, to a specific network interface, e.g. eth0, use this command:

  • sudo ufw deny in on eth0 from 15.15.15.51

This is the same as the previous example, with the addition of in on eth0. The network interface can be specified in any firewall rule, and is a great way to limit the rule to a particular network.

Service: SSH

If you’re using a cloud server, you will probably want to allow incoming SSH connections (port 22) so you can connect to and manage your server. This section covers how to configure your firewall with various SSH-related rules.

Allow SSH

To allow all incoming SSH connections run this command:

  • sudo ufw allow ssh

An alternative syntax is to specify the port number of the SSH service:

  • sudo ufw allow 22

Allow Incoming SSH from Specific IP Address or Subnet

To allow incoming SSH connections from a specific IP address or subnet, specify the source. For example, if you want to allow the entire 15.15.15.0/24 subnet, run this command:

  • sudo ufw allow from 15.15.15.0/24 to any port 22

Allow Incoming Rsync from Specific IP Address or Subnet

Rsync, which runs on port 873, can be used to transfer files from one computer to another.

To allow incoming rsync connections from a specific IP address or subnet, specify the source IP address and the destination port. For example, if you want to allow the entire 15.15.15.0/24 subnet to be able to rsync to your server, run this command:

  • sudo ufw allow from 15.15.15.0/24 to any port 873

Service: Web Server

Web servers, such as Apache and Nginx, typically listen for requests on port 80 and 443 for HTTP and HTTPS connections, respectively. If your default policy for incoming traffic is set to drop or deny, you will want to create rules that will allow your server to respond to those requests.

Allow All Incoming HTTP

To allow all incoming HTTP (port 80) connections run this command:

  • sudo ufw allow http

An alternative syntax is to specify the port number of the HTTP service:

  • sudo ufw allow 80

Allow All Incoming HTTPS

To allow all incoming HTTPS (port 443) connections run this command:

  • sudo ufw allow https

An alternative syntax is to specify the port number of the HTTPS service:

  • sudo ufw allow 443

Allow All Incoming HTTP and HTTPS

If you want to allow both HTTP and HTTPS traffic, you can create a single rule that allows both ports. To allow all incoming HTTP and HTTPS (port 443) connections run this command:

  • sudo ufw allow proto tcp from any to any port 80,443

Note that you need to specify the protocol, with proto tcp, when specifying multiple ports.

Service: MySQL

MySQL listens for client connections on port 3306. If your MySQL database server is being used by a client on a remote server, you need to be sure to allow that traffic.

Allow MySQL from Specific IP Address or Subnet

To allow incoming MySQL connections from a specific IP address or subnet, specify the source. For example, if you want to allow the entire 15.15.15.0/24 subnet, run this command:

  • sudo ufw allow from 15.15.15.0/24 to any port 3306

Allow MySQL to Specific Network Interface

To allow MySQL connections to a specific network interface—say you have a private network interface eth1, for example—use this command:

  • sudo ufw allow in on eth1 to any port 3306
  • sudo ufw allow 3306/tcp
    sudo service ufw restart

Service: PostgreSQL

PostgreSQL listens for client connections on port 5432. If your PostgreSQL database server is being used by a client on a remote server, you need to be sure to allow that traffic.

PostgreSQL from Specific IP Address or Subnet

To allow incoming PostgreSQL connections from a specific IP address or subnet, specify the source. For example, if you want to allow the entire 15.15.15.0/24 subnet, run this command:

  • sudo ufw allow from 15.15.15.0/24 to any port 5432

The second command, which allows the outgoing traffic of established PostgreSQL connections, is only necessary if the OUTPUT policy is not set to ACCEPT.

Allow PostgreSQL to Specific Network Interface

To allow PostgreSQL connections to a specific network interface—say you have a private network interface eth1, for example—use this command:

  • sudo ufw allow in on eth1 to any port 5432

The second command, which allows the outgoing traffic of established PostgreSQL connections, is only necessary if the OUTPUT policy is not set to ACCEPT.

Service: Mail

Mail servers, such as Sendmail and Postfix, listen on a variety of ports depending on the protocols being used for mail delivery. If you are running a mail server, determine which protocols you are using and allow the appropriate types of traffic. We will also show you how to create a rule to block outgoing SMTP mail.

Block Outgoing SMTP Mail

If your server shouldn’t be sending outgoing mail, you may want to block that kind of traffic. To block outgoing SMTP mail, which uses port 25, run this command:

  • sudo ufw deny out 25

This configures your firewall to drop all outgoing traffic on port 25. If you need to reject a different service by its port number, instead of port 25, simply replace it.

Allow All Incoming SMTP

To allow your server to respond to SMTP connections, port 25, run this command:

  • sudo ufw allow 25

Note: It is common for SMTP servers to use port 587 for outbound mail.

Allow All Incoming IMAP

To allow your server to respond to IMAP connections, port 143, run this command:

  • sudo ufw allow 143

Allow All Incoming IMAPS

To allow your server to respond to IMAPS connections, port 993, run this command:

  • sudo ufw allow 993

Allow All Incoming POP3

To allow your server to respond to POP3 connections, port 110, run this command:

  • sudo ufw allow 110

Allow All Incoming POP3S

To allow your server to respond to POP3S connections, port 995, run this command:

  • sudo ufw allow 995
  • sudo apt-get install ufw

=========================================================================

Reference

https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu-14-04

Using IPv6 with UFW

If your Ubuntu server has IPv6 enabled, ensure that UFW is configured to support IPv6 so that it will manage firewall rules for IPv6 in addition to IPv4. To do this, open the UFW configuration with your favorite editor. We’ll use nano:

  • sudo nano /etc/default/ufw

Then make sure the value of “IPV6” is to equal “yes”. It should look like this:

/etc/default/ufw excerpt
...
IPV6=yes
...

Save and quit. Hit Ctrl-X to exit the file, then Y to save the changes that you made, then ENTER to confirm the file name.

When UFW is enabled, it will be configured to write both IPv4 and IPv6 firewall rules.

This tutorial is written with IPv4 in mind, but will work fine for IPv6 as long as you enable it.

Check UFW Status and Rules

At any time, you can check the status of UFW with this command:

  • sudo ufw status verbose

By default, UFW is disabled so you should see something like this:

Output:
Status: inactive

If UFW is active, the output will say that it’s active, and it will list any rules that are set. For example, if the firewall is set to allow SSH (port 22) connections from anywhere, the output might look something like this:

Output:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere

As such, use the status command if you ever need to check how UFW has configured the firewall.

Before enabling UFW, we will want to ensure that your firewall is configured to allow you to connect via SSH. Let’s start with setting the default policies.

Set Up Default Policies

If you’re just getting started with your firewall, the first rules to define are your default policies. These rules control how to handle traffic that does not explicitly match any other rules. By default, UFW is set to deny all incoming connections and allow all outgoing connections. This means anyone trying to reach your cloud server would not be able to connect, while any application within the server would be able to reach the outside world.

Let’s set your UFW rules back to the defaults so we can be sure that you’ll be able to follow along with this tutorial. To set the defaults used by UFW, use these commands:

  • sudo ufw default deny incoming
  • sudo ufw default allow outgoing

As you might have guessed, these commands set the defaults to deny incoming and allow outgoing connections. These firewall defaults, by themselves, might suffice for a personal computer but servers typically need to respond to incoming requests from outside users. We’ll look into that next.

Allow SSH Connections

If we enabled our UFW firewall now, it would deny all incoming connections. This means that we will need to create rules that explicitly allow legitimate incoming connections—SSH or HTTP connections, for example—if we want our server to respond to those types of requests. If you’re using a cloud server, you will probably want to allow incoming SSH connections so you can connect to and manage your server.

To configure your server to allow incoming SSH connections, you can use this UFW command:

  • sudo ufw allow ssh

This will create firewall rules that will allow all connections on port 22, which is the port that the SSH daemon listens on. UFW knows what “ssh”, and a bunch of other service names, means because it’s listed as a service that uses port 22 in the /etc/services file.

We can actually write the equivalent rule by specifying the port instead of the service name. For example, this command works the same as the one above:

  • sudo ufw allow 22

If you configured your SSH daemon to use a different port, you will have to specify the appropriate port. For example, if your SSH server is listening on port 2222, you can use this command to allow connections on that port:

  • sudo ufw allow 2222

Now that your firewall is configured to allow incoming SSH connections, we can enable it.

Enable UFW

To enable UFW, use this command:

  • sudo ufw enable

You will receive a warning that says the “command may disrupt existing ssh connections.” We already set up a firewall rule that allows SSH connections so it should be fine to continue. Respond to the prompt with y.

The firewall is now active. Feel free to run the sudo ufw status verbose command to see the rules that are set.

Allow Other Connections

Now you should allow all of the other connections that your server needs to respond to. The connections that you should allow depends your specific needs. Luckily, you already know how to write rules that allow connections based on a service name or port—we already did this for SSH on port 22.

We will show a few examples of very common services that you may need to allow. If you have any other services for which you want to allow all incoming connections, follow this format.

HTTP—port 80

HTTP connections, which is what unencrypted web servers use, can be allowed with this command:

  • sudo ufw allow http

If you’d rather use the port number, 80, use this command:

  • sudo ufw allow 80

HTTPS—port 443

HTTPS connections, which is what encrypted web servers use, can be allowed with this command:

  • sudo ufw allow https

If you’d rather use the port number, 443, use this command:

  • sudo ufw allow 443

FTP—port 21

FTP connections, which is used for unencrypted file transfers (which you probably shouldn’t use anyway), can be allowed with this command:

  • sudo ufw allow ftp

If you’d rather use the port number, 21, use this command:

  • sudo ufw allow 21/tcp

Allow Specific Port Ranges

You can specify port ranges with UFW. Some applications use multiple ports, instead of a single port.

For example, to allow X11 connections, which use ports 6000-6007, use these commands:

  • sudo ufw allow 6000:6007/tcp
  • sudo ufw allow 6000:6007/udp

When specifying port ranges with UFW, you must specify the protocol (tcp or udp) that the rules should apply to. We haven’t mentioned this before because not specifying the protocol simply allows both protocols, which is OK in most cases.

Allow Specific IP Addresses

When working with UFW, you can also specify IP addresses. For example, if you want to allow connections from a specific IP address, such as a work or home IP address of 15.15.15.51, you need to specify “from” then the IP address:

  • sudo ufw allow from 15.15.15.51

You can also specify a specific port that the IP address is allowed to connect to by adding “to any port” followed by the port number. For example, If you want to allow 15.15.15.51 to connect to port 22 (SSH), use this command:

sudo ufw allow from 15.15.15.51 to any port 22

Allow Subnets

If you want to allow a subnet of IP addresses, you can do so using CIDR notation to specify a netmask. For example, if you want to allow all of the IP addresses ranging from 15.15.15.1 to 15.15.15.254 you could use this command:

  • sudo ufw allow from 15.15.15.0/24

Likewise, you may also specify the destination port that the subnet 15.15.15.0/24 is allowed to connect to. Again, we’ll use port 22 (SSH) as an example:

sudo ufw allow from 15.15.15.0/24 to any port 22

Allow Connections to a Specific Network Interface

If you want to create a firewall rule that only applies to a specific network interface, you can do so by specifying “allow in on” followed by the name of the network interface.

You may want to look up your network interfaces before continuing. To do so, use this command:

  • ip addr
Output Excerpt:
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
...
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
...

The highlighted output indicates the network interface names. They are typically named something like “eth0” or “eth1”.

So, if your server has a public network interface called eth0, you could allow HTTP traffic (port 80) to it with this command:

  • sudo ufw allow in on eth0 to any port 80

Doing so would allow your server to receive HTTP requests from the public Internet.

Or, if you want your MySQL database server (port 3306) to listen for connections on the private network interface eth1, for example, you could use this command:

  • sudo ufw allow in on eth1 to any port 3306

This would allow other servers on your private network to connect to your MySQL database.

Deny Connections

If you haven’t changed the default policy for incoming connections, UFW is configured to deny all incoming connections. Generally, this simplifies the process of creating a secure firewall policy by requiring you to create rules that explicitly allow specific ports and IP addresses through. However, sometimes you will want to deny specific connections based on the source IP address or subnet, perhaps because you know that your server is being attacked from there. Also, if you want change your default incoming policy to allow (which isn’t recommended in the interest of security), you would need to create deny rules for any services or IP addresses that you don’t want to allow connections for.

To write deny rules, you can use the commands that we described above except you need to replace “allow” with “deny”.

For example to deny HTTP connections, you could use this command:

  • sudo ufw deny http

Or if you want to deny all connections from 15.15.15.51 you could use this command:

sudo ufw deny from 15.15.15.51

If you need help writing any other deny rules, just look at the previous allow rules and update them accordingly.

Now let’s take a look at how to delete rules.

Delete Rules

Knowing how to delete firewall rules is just as important as knowing how to create them. There are two different ways specify which rules to delete: by rule number or by the actual rule (similar to how the rules were specified when they were created). We’ll start with the delete by rule number method because it is easier, compared to writing the actual rules to delete, if you’re new to UFW.

By Rule Number

If you’re using the rule number to delete firewall rules, the first thing you’ll want to do is get a list of your firewall rules. The UFW status command has an option to display numbers next to each rule, as demonstrated here:

  • sudo ufw status numbered
Numbered Output:
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22                         ALLOW IN    15.15.15.0/24
[ 2] 80                         ALLOW IN    Anywhere

If we decide that we want to delete rule 2, the one that allows port 80 (HTTP) connections, we can specify it in a UFW delete command like this:

  • sudo ufw delete 2

This would show a confirmation prompt then delete rule 2, which allows HTTP connections. Note that if you have IPv6 enabled, you would want to delete the corresponding IPv6 rule as well.

By Actual Rule

The alternative to rule numbers is to specify the actual rule to delete. For example, if you want to remove the “allow http” rule, you could write it like this:

  • sudo ufw delete allow http

You could also specify the rule by “allow 80”, instead of by service name:

  • sudo ufw delete allow 80

This method will delete both IPv4 and IPv6 rules, if they exist.

How To Disable UFW (optional)

If you decide you don’t want to use UFW for whatever reason, you can disable it with this command:

  • sudo ufw disable

Any rules that you created with UFW will no longer be active. You can always run sudo ufw enable if you need to activate it later.

Reset UFW Rules (optional)

If you already have UFW rules configured but you decide that you want to start over, you can use the reset command:

  • sudo ufw reset

This will disable UFW and delete any rules that were previously defined. Keep in mind that the default policies won’t change to their original settings, if you modified them at any point. This should give you a fresh start with UFW.