UFW (uncomplicated firewall) is a command-line tool designed to simplify firewall management on Linux systems, particularly those based on Ubuntu. Built on top of iptables
, it provides a user-friendly way to define rules for controlling network traffic, such as allowing or blocking specific ports, IP addresses, or services. UFW is relevant for system administrators and developers who need to secure servers without dealing with the complexity of raw iptables
commands, offering a straightforward approach to managing both IPv4 and IPv6 traffic.
This cheat sheet-style guide provides a quick reference to common UFW use cases and commands, including examples of how to allow and block services by port, network interface, and source IP address. It also covers default policies, application profiles, SSH access, and advanced usage scenarios, making it a practical resource for securely managing firewall rules on Ubuntu systems.
UFW Simplifies Firewall Management: UFW is a user-friendly interface for managing iptables
, designed to simplify firewall configuration on Ubuntu-based systems.
Default Policies Are Secure by Design: By default, UFW denies all incoming connections and allows all outgoing connections, creating a secure baseline for most servers.
Always Allow SSH Before Enabling UFW: If you’re connected via SSH, enable SSH access with sudo ufw allow OpenSSH
before activating UFW to avoid losing remote access.
Use Application Profiles When Available: UFW integrates with application profiles (e.g., Nginx Full, OpenSSH), allowing easier rule creation without specifying port numbers manually.
Support for IP-Based Rules: You can allow or block traffic from specific IP addresses or subnets using simple commands like ufw allow from IP
or ufw deny from subnet
.
Interface-Specific Rules Offer Granular Control: UFW allows rule targeting per network interface, which is useful for multi-interface systems and virtualized environments.
UFW Integrates with Both IPv4 and IPv6: Rules apply to both IP versions unless explicitly disabled. You’ll see (v6)
entries in the status output for IPv6 rules.
Docker Can Conflict with UFW: Docker modifies iptables
directly, potentially bypassing UFW rules unless additional configuration is applied.
UFW Rules Can Be Reset or Deleted Easily: Use ufw reset
to wipe all rules or ufw delete
to remove specific ones, including by rule number for precision.
Best Practices Enhance Security and Maintainability: The guide emphasizes clear practices: setting default policies early, backing up rule sets, using logging, and avoiding use of firewalld
alongside UFW.
<$>
Remember that you can check your current UFW ruleset with sudo ufw status
or sudo ufw status verbose
.
Deploy your frontend applications from GitHub using DigitalOcean App Platform. Let DigitalOcean focus on scaling your app.
To check if ufw
is enabled, run:
- sudo ufw status
Status: inactive
The output will indicate if your firewall is active or not.
If you get a Status: inactive
message when running ufw status
, it means the firewall is not yet enabled on the system. You’ll need to run a command to enable it.
Note: By default, when enabled UFW will block external access to all ports on a server. In practice, that means if you are connected to a server via SSH and enable UFW before allowing access via the SSH port, you’ll be disconnected. Make sure you follow the section in this guide on how to enable SSH access before enabling the firewall if that’s your case.
To enable UFW on your system, run:
- sudo ufw enable
You’ll see output like this:
Firewall is active and enabled on system startup
When you enable UFW for the first time, it applies a set of default policies that define how the firewall handles incoming and outgoing connections. By default, UFW is configured to:
You can verify the current default policy settings with the following command:
- sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip
If you want to change the default behavior, you can update the default policies using the following commands:
To deny all incoming connections (recommended for most servers):
- sudo ufw default deny incoming
To allow all outgoing connections (the default):
- sudo ufw default allow outgoing
To deny all forwarded traffic (relevant for routers and gateways):
- sudo ufw default deny routed
These default rules act as a baseline. Once set, you can explicitly allow trusted connections using ufw allow
rules, as described in the other sections of this guide.
You can always reapply or reset your default policies as needed, depending on how restrictive or open you want your firewall to be.
If, for some reason, you need to disable UFW, you can do so with the following command:
- sudo ufw disable
Be aware that this command will fully disable the firewall service on your system.
iptables
UFW is a user-friendly front-end for managing iptables, the underlying packet filtering framework used by most Linux systems. When you configure firewall rules using UFW, it translates those rules into iptables syntax behind the scenes.
This means that:
To check whether UFW is managing your iptables rules, you can inspect the raw iptables output:
- sudo iptables -L
You’ll see chains like ufw-before-input
, ufw-user-input
, and others, which are automatically created and managed by UFW to enforce its policies.
UFW stores its persistent rule definitions in configuration files, typically under:
/etc/ufw/
Most users never need to edit these files directly. However, if you also manage iptables rules manually or through other tools (like Docker or custom scripts), you should be aware that UFW might overwrite or conflict with those rules.
Tip: If you’re running UFW and also applying manual iptables rules, it’s best to apply custom rules through UFW or use UFW’s before.rules
and after.rules
configuration files to ensure compatibility.
While UFW simplifies rule management, iptables still does the actual packet filtering at the kernel level. Think of UFW as a command-line assistant that speaks iptables fluently, so you don’t have to.
To block all network connections that originate from a specific IP address, run the following command, replacing the highlighted IP address with the IP address that you want to block:
- sudo ufw deny from 203.0.113.100
Rule added
In this example, from 203.0.113.100
specifies a source IP address of “203.0.113.100”.
If you run sudo ufw status
now, you’ll see the specified IP address listed as denied:
Status: active
To Action From
-- ------ ----
Anywhere DENY 203.0.113.100
All connections, coming in or going out, are blocked for the specified IP address.
If you need to block a full subnet, you can use the subnet address with the from
parameter in the ufw deny
command. This would block all IP addresses in the example subnet 203.0.113.0/24
:
- sudo ufw deny from 203.0.113.0/24
Rule added
To block incoming connections from a specific IP address to a specific network interface, run the following command, replacing the highlighted IP address with the IP address you want to block:
- sudo ufw deny in on eth0 from 203.0.113.100
Rule added
The in
parameter tells ufw
to apply the rule only for incoming connections, and the on eth0
parameter specifies that the rule applies only for the eth0
interface. This might be useful if you have a system with several network interfaces (including virtual ones) and you need to block external access to some of these interfaces, but not all.
To allow all network connections that originate from a specific IP address, run the following command, replacing the highlighted IP address with the IP address that you want to allow access:
- sudo ufw allow from 203.0.113.101
Rule added
If you run sudo ufw status
now, you’ll see output similar to this, showing the word ALLOW
next to the IP address you just added.
Status: active
To Action From
-- ------ ----
...
Anywhere ALLOW 203.0.113.101
You can also allow connections from a whole subnet by providing the corresponding subnet mask for a host, such as 203.0.113.0/24
.
To allow incoming connections from a specific IP address to a specific network interface, run the following command, replacing the highlighted IP address with the IP address you want to allow:
- sudo ufw allow in on eth0 from 203.0.113.102
Rule added
The in
parameter tells ufw
to apply the rule only for incoming connections, and the on eth0
parameter specifies that the rule applies only for the eth0
interface.
If you run sudo ufw status
now, you’ll see output similar to this:
Status: active
To Action From
-- ------ ----
...
Anywhere on eth0 ALLOW 203.0.113.102
To delete a rule that you previously set up within UFW, use ufw delete
followed by the rule (allow
or deny
) and the target specification. The following example would delete a rule previously set to allow all connections from an IP address of 203.0.113.101
:
- sudo ufw delete allow from 203.0.113.101
Rule deleted
Another way to specify which rule you want to delete is by providing the rule ID. This information can be obtained with the following command:
- sudo ufw status numbered
Status: active
To Action From
-- ------ ----
[ 1] Anywhere DENY IN 203.0.113.100
[ 2] Anywhere on eth0 ALLOW IN 203.0.113.102
From the output, you can see that there are two active rules. The first rule, with highlighted values, denies all connections coming from the IP address 203.0.113.100
. The second rule allows connections on the eth0
interface coming in from the IP address 203.0.113.102
.
Because UFW’s default policy denies all incoming traffic, a specific DENY
rule is only necessary to override a more permissive ALLOW
rule. You can remove this rule if you don’t have any conflicting ALLOW
rules for that source.
To delete a rule by its ID, run:
- sudo ufw delete 1
You will be prompted to confirm the operation and to make sure the ID you’re providing refers to the correct rule you want to delete.
Deleting:
deny from 203.0.113.100
Proceed with operation (y|n)? y
Rule deleted
If you list your rules again with sudo ufw status
, you’ll see that the rule was removed.
Upon installation, applications that rely on network communications will typically set up a UFW profile that you can use to allow connections from external addresses. This is often the same as running ufw allow from
, with the advantage of providing a shortcut that abstracts the specific port numbers a service uses and provides a user-friendly nomenclature to referenced services.
To list which profiles are currently available, run the following:
- sudo ufw app list
If you installed a service such as a web server or other network-dependent software and a profile was not made available within UFW, first make sure the service is enabled. For remote servers, you’ll typically have OpenSSH readily available:
Available applications:
OpenSSH
To enable a UFW application profile, run ufw allow
followed by the name of the application profile you want to enable, which you can obtain with a sudo ufw app list
command. In the following example, we’re enabling the OpenSSH profile, which will allow all incoming SSH connections on the default SSH port.
- sudo ufw allow "OpenSSH"
Rule added
Rule added (v6)
Remember to quote profile names that consist of multiple words, such as Nginx HTTPS
.
To disable an application profile that you had previously set up within UFW, you’ll need to remove its corresponding rule. For example, consider the following output from sudo ufw status
:
- sudo ufw status
Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx Full ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx Full (v6) ALLOW Anywhere (v6)
This output indicates that the Nginx Full
application profile is currently enabled, allowing any and all connections to the web server both via HTTP and via HTTPS. If you want to allow only HTTPS requests from and to your web server, you must first enable the most restrictive rule, which in this case would be Nginx HTTPS
, and then disable the currently active Nginx Full
rule:
- sudo ufw allow "Nginx HTTPS"
- sudo ufw delete allow "Nginx Full"
Remember, you can list all available application profiles with sudo ufw app list
.
When working with remote servers, you’ll want to make sure that the SSH port is open to connections so that you are able to log in to your server remotely.
The following command will enable the OpenSSH UFW application profile and allow all connections to the default SSH port on the server:
- sudo ufw allow OpenSSH
Rule added
Rule added (v6)
Although less user-friendly, an alternative syntax is to specify the exact port number of the SSH service, which is typically set to 22
by default:
- sudo ufw allow 22
Rule added
Rule added (v6)
To allow incoming connections from a specific IP address or subnet, use a from
directive to define the source of the connection. This will require that you also specify the destination address with a to
parameter. To lock this rule to SSH only, you’ll limit the proto
(protocol) to tcp
and then use the port
parameter and set it to 22
, SSH’s default port.
The following command will allow only SSH connections coming from the IP address 203.0.113.103
:
- sudo ufw allow from 203.0.113.103 proto tcp to any port 22
Rule added
You can also use a subnet address as from
parameter to allow incoming SSH connections from an entire network:
- sudo ufw allow from 203.0.113.0/24 proto tcp to any port 22
Rule added
The Rsync program, 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, use the from
parameter to specify the source IP address and the port
parameter to set the destination port 873
.
The following command will allow only Rsync connections coming from the IP address 203.0.113.103
:
- sudo ufw allow from 203.0.113.103 to any port 873
Rule added
To allow the entire 203.0.113.0/24
subnet to connect to your server via rsync
:
- sudo ufw allow from 203.0.113.0/24 to any port 873
Rule added
Upon installation, the Nginx web server sets up a few different UFW profiles within the server. Once you have Nginx installed and enabled as a service, run the following command to identify which profiles are available:
- sudo ufw app list | grep Nginx
Nginx Full
Nginx HTTP
Nginx HTTPS
To enable both HTTP and HTTPS traffic, choose Nginx Full
. Otherwise, choose either Nginx HTTP
to allow only HTTP or Nginx HTTPS
to allow only HTTPS.
The following command will allow both HTTP and HTTPS traffic on the server (ports 80
and 443
):
- sudo ufw allow "Nginx Full"
Rule added
Rule added (v6)
Upon installation, the Apache web server sets up a few different UFW profiles within the server. Once you have Apache installed and enabled as a service, run the following command to identify which profiles are available:
- sudo ufw app list | grep Apache
Apache
Apache Full
Apache Secure
To enable both HTTP and HTTPS traffic, choose Apache Full
. Otherwise, choose either Apache
for HTTP or Apache Secure
for HTTPS.
The following command will allow both HTTP and HTTPS traffic on the server (ports 80
and 443
):
- sudo ufw allow "Apache Full"
Rule added
Rule added (v6)
80
)Web servers, such as Apache and Nginx, typically listen for HTTP requests on port 80
. If your default policy for incoming traffic is set to drop or deny, you’ll need to create a UFW rule to allow external access on port 80
. You can use either the port number or the service name (http
) as a parameter to this command.
To allow all incoming HTTP (port 80
) connections, run:
- sudo ufw allow http
Rule added
Rule added (v6)
An alternative syntax is to specify the port number of the HTTP service:
- sudo ufw allow 80
Rule added
Rule added (v6)
443
)HTTPS typically runs on port 443
. If your default policy for incoming traffic is set to drop or deny, you’ll need to create a UFW rule to allow external access on port 443
. You can use either the port number or the service name (https
) as a parameter to this command.
To allow all incoming HTTPS (port 443
) connections, run:
- sudo ufw allow https
Rule added
Rule added (v6)
An alternative syntax is to specify the port number of the HTTPS service:
- sudo ufw allow 443
Rule added
Rule added (v6)
If you want to allow both HTTP and HTTPS traffic, you can create a single rule to allow traffic on both ports simultaneously. This usage requires that you also define the protocol with the proto
parameter, which in this case should be set to tcp
.
To allow all incoming HTTP and HTTPS (ports 80
and 443
) connections, run:
- sudo ufw allow proto tcp from any to any port 80,443
Rule added
Rule added (v6)
MySQL listens for client connections on port 3306
. If your MySQL database server is being used by a client on a remote server, you’ll need to create a UFW rule to allow that access.
To allow incoming MySQL connections from a specific IP address or subnet, use the from
parameter to specify the source IP address and the port
parameter to set the destination port 3306
.
The following command will allow the IP address 203.0.113.103
to connect to the server’s MySQL port:
- sudo ufw allow from 203.0.113.103 to any port 3306
Rule added
To allow the entire 203.0.113.0/24
subnet to be able to connect to your MySQL server, run:
- sudo ufw allow from 203.0.113.0/24 to any port 3306
Rule added
PostgreSQL listens for client connections on port 5432
. If your PostgreSQL database server is being used by a client on a remote server, you must explicitly allow this traffic.
To allow incoming PostgreSQL connections from a specific IP address or subnet, specify the source with the from
parameter, and set the port to 5432
:
- sudo ufw allow from 203.0.113.103 to any port 5432
Rule added
To allow the entire 203.0.113.0/24
subnet to be able to connect to your PostgreSQL server, run:
- sudo ufw allow from 203.0.113.0/24 to any port 5432
Rule added
Mail servers, such as Sendmail and Postfix, typically use port 25
for SMTP traffic. If your server shouldn’t be sending outgoing mail, you may want to block that kind of traffic. To block outgoing SMTP connections, run:
- sudo ufw deny out 25
Rule added
Rule added (v6)
This configures your firewall to drop all outgoing traffic on port 25
. If you need to reject outgoing connections on a different port number, you can repeat this command and replace 25
with the port number you want to block.
Over time, your UFW rule set may grow cluttered with test rules, duplicate entries, or outdated configurations. If you need a clean slate, UFW provides a built-in command to reset its configuration back to the default state.
Resetting UFW will:
deny
for all incoming trafficallow
for all outgoing trafficTo perform a full reset of UFW, run the following command:
- sudo ufw reset
Resetting all rules to installed defaults. This may disrupt existing ssh connections. Proceed with operation (y|n)?
Type y
to confirm.
This action is useful when:
Note: If you’re connected to the server remotely via SSH, do not reset UFW unless you’re prepared to immediately re-allow SSH access. Otherwise, you risk locking yourself out once the firewall is re-enabled.
Once you’ve reset UFW, you’ll need to reconfigure essential access rules. For example, to re-allow SSH and activate the firewall again:
- sudo ufw allow OpenSSH
- sudo ufw enable
You can then rebuild your rule set from scratch based on your current needs.
While UFW is the default firewall manager on Ubuntu-based systems, other Linux distributions, especially Red Hat-based ones, use a different tool: firewalld. Both tools serve the same purpose of managing firewall rules, but they take different approaches and are designed with different priorities in mind.
firewalld is a firewall management tool that provides a dynamic interface for managing rules. It utilizes the concept of zones, which lets you define different trust levels for network interfaces (for example: public, internal, dmz). This makes it ideal for more complex environments where different parts of the system or network require different firewall behavior.
firewalld supports both runtime and permanent rules. Runtime changes take effect immediately without restarting the service, making it suitable for on-the-fly updates. Permanent rules persist across reboots and are typically used for long-term configuration.
It also includes rich rule support (such as service-based access, ICMP types, interface filtering, and source/destination address control) and is often managed through graphical tools like firewall-config or Cockpit.
Feature | UFW | firewalld |
---|---|---|
Default on | Ubuntu, Debian | RHEL, CentOS, Fedora |
Configuration style | Static, rule-based | Dynamic, zone-based |
Zones | Not supported | Fully supported |
Rule types | Persistent | Runtime and permanent |
GUI support | GUFW (Graphical Uncomplicated Firewall) (basic) | firewall-config, Cockpit (advanced) |
Syntax simplicity | Simple, human-readable CLI | More flexible but more complex |
Backend | iptables or nftables (indirectly) | iptables or nftables |
Use case focus | Basic host firewalling | Multi-interface, multi-zone environments |
Note: Avoid using UFW and firewalld on the same system. They manage the same underlying iptables or nftables rules and can conflict with each other, causing unexpected behavior.
To check if firewalld is running on your system:
- sudo systemctl status firewalld
To stop and disable it if you are using UFW, use the following commands:
- sudo systemctl stop firewalld
- sudo systemctl disable firewalld
To get the most out of UFW while minimizing misconfigurations and downtime, consider following these recommended best practices when setting up and maintaining your firewall.
If you’re connected to a server over SSH, make sure to allow SSH before enabling UFW to avoid being locked out:
- sudo ufw allow OpenSSH
- sudo ufw enable
Failing to do this will block your remote access the moment UFW is enabled.
Set your default incoming and outgoing policies early in your configuration so you’re starting with a secure baseline:
- sudo ufw default deny incoming
- sudo ufw default allow outgoing
Only then should you begin explicitly allowing the services you need.
Instead of manually allowing ports, use predefined application profiles:
- sudo ufw allow "Nginx Full"
To see what profiles are available:
- sudo ufw app list
This makes rule management easier and reduces the chance of human error when typing port numbers or protocols.
Limit exposure by tightening rules as much as possible. For example, instead of opening SSH to the world:
- sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
This approach minimizes your server’s attack surface by only allowing trusted sources.
When you need to remove or audit specific rules, use:
- sudo ufw status numbered
This makes it easier to delete rules precisely without needing to retype full command strings:
- sudo ufw delete 2
Firewall misconfigurations can disrupt services. If you’re modifying rules on a production server, test during off-peak hours or schedule a short maintenance window to reduce risk.
Enable logging to capture dropped connections and debug firewall behavior:
- sudo ufw logging on
Logs are typically stored in:
- /var/log/ufw.log
You can control verbosity with:
- sudo ufw logging low # or medium / high / full
Before resetting or reworking your UFW configuration, save the current ruleset:
- sudo ufw status numbered > ufw-backup.txt
This lets you recreate or review past configurations if something goes wrong.
Stick to one firewall management system. Running both UFW and firewalld simultaneously can cause rule conflicts and unpredictable behavior.
Disable the one you’re not using:
- sudo systemctl disable firewalld
Or:
- sudo ufw disable
Following these best practices will help ensure your firewall is secure, maintainable, and doesn’t interrupt your server’s connectivity.
By default, UFW is configured to deny all incoming connections and allow all outgoing connections. This means no external device can initiate a connection to your system unless explicitly allowed, while your system is free to access external resources.
You can view the current default policies by running:
- sudo ufw status verbose
To change the defaults, use:
- sudo ufw default deny incoming
- sudo ufw default allow outgoing
To allow all traffic from a specific IP address, use the allow from
syntax. Replace the IP with the address you want to permit:
- sudo ufw allow from 203.0.113.101
This creates a rule that permits all types of connections from that IP to your server. If you want to restrict it to a specific port or protocol, you can add more parameters:
- sudo ufw allow from 203.0.113.101 to any port 22 proto tcp
This allows only SSH (TCP port 22
) traffic from the given IP.
To view your active UFW rules, run:
- sudo ufw status
For more detailed output, including default policies and logging status, use the verbose
flag:
- sudo ufw status verbose
If you want to view rules with line numbers (helpful for deleting specific rules), run:
- sudo ufw status numbered
Yes, UFW can be used to block outgoing connections. While UFW allows all outbound traffic by default, you can add rules to deny specific ports or destinations.
To block all outgoing SMTP traffic on port 25
, for example:
- sudo ufw deny out 25
You can also block outgoing traffic to specific IP addresses or ranges:
- sudo ufw deny out to 203.0.113.0/24
To change the default policy for all outbound traffic:
- sudo ufw default deny outgoing
Be cautious with outbound rules, especially on servers that require external access for updates, backups, or package installations.
Yes, UFW supports both IPv4 and IPv6 by default. When you enable a rule like sudo ufw allow ssh
, it creates rules for both IPv4 and IPv6 unless configured otherwise.
You can verify IPv6 rules are active by checking the output of:
- sudo ufw status
You’ll see entries like:
OpenSSH (v6) ALLOW Anywhere (v6)
To disable IPv6 support in UFW, edit the configuration file:
- sudo nano /etc/default/ufw
Set:
IPV6=no
Then reload UFW:
- sudo ufw disable && sudo ufw enable
UFW and Docker can conflict because Docker bypasses the default iptables rules UFW sets up. As a result, Docker containers may be exposed to the network even if UFW appears to block traffic.
If you’re running Docker and need strict firewall control, you’ll need to:
To secure your system while running Docker, consider using Docker’s --iptables=false
option and managing container traffic manually, or use advanced UFW/Docker integration scripts.
Note: By default, Docker modifies iptables directly. This can override or bypass UFW rules unless explicitly accounted for.
There are two main ways to delete a UFW rule:
By repeating the exact rule:
- sudo ufw delete allow from 203.0.113.101
By rule number:
First, list rules with numbers:
- sudo ufw status numbered
Then delete a rule by its number:
- sudo ufw delete 2
You’ll be prompted to confirm the deletion before the rule is removed.
Many networked applications (like Nginx, Apache, or OpenSSH) register UFW profiles when installed. You can view all available profiles with:
- sudo ufw app list
To see what ports a profile covers, run:
- sudo ufw app info "Nginx Full"
This will show which ports the profile opens and any associated protocols. Using application profiles simplifies rule management and abstracts away the need to remember specific port numbers.
UFW is a powerful yet approachable tool for managing firewall rules on Ubuntu systems. With its simple syntax and built-in support for both IPv4 and IPv6, UFW makes it easy to enforce access controls without needing to write complex iptables
rules by hand.
This guide has covered the most common UFW commands and use cases, including how to allow or deny traffic by port, IP address, and network interface, as well as how to manage application profiles and reset the firewall configuration. Most of these examples can be adapted to fit your own network needs by modifying parameters like IP addresses or port numbers.
For more in-depth details on UFW command options and advanced usage, consult the manual using man ufw
or explore Ubuntu’s official documentation.
To explore and learn more about firewall configuration and Linux networking, check out these helpful resources:
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
Software Engineer @ DigitalOcean. Former Señor Technical Writer (I no longer update articles or respond to comments). Expertise in areas including Ubuntu, PostgreSQL, MySQL, and more.
Dev/Ops passionate about open source, PHP, and Linux. Former Senior Technical Writer at DigitalOcean. Areas of expertise include LAMP Stack, Ubuntu, Debian 11, Linux, Ansible, and more.
With over 6 years of experience in tech publishing, Mani has edited and published more than 75 books covering a wide range of data science topics. Known for his strong attention to detail and technical knowledge, Mani specializes in creating clear, concise, and easy-to-understand content tailored for developers.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
sudo ufw deny in on eth0 from 15.15.15.51
Cool! But how to do it in CentOS?
Should the following command block web traffic as well? Meaning, prevent anyone accessing from this IP address from accessing any websites on the server?
sudo ufw deny from 15.15.15.51
“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 25
This actully will block incoming SMTP traffic, not outgoing! Please fix this. The correct command is
sudo ufw deny out 25
I’m wondering if you can tell me what the following UFW log entries mean? (I replaced my server IP with xxx.xxx.xxx.xxx):
Feb 3 14:40:48 www kernel: [149871.434419] [UFW BLOCK] IN=eth0 OUT= MAC=04:01:4b:83:f5:01:84:b5:9c:f9:18:30:08:00 SRC=205.204.2.28 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=33554 PROTO=TCP SPT=1702 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Feb 3 14:41:08 www kernel: [149891.197907] [UFW BLOCK] IN=eth0 OUT= MAC=04:01:4b:83:f5:01:84:b5:9c:f9:18:30:08:00 SRC=149.101.37.2 DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=47 ID=23953 PROTO=TCP SPT=44916 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Feb 3 14:41:28 www kernel: [149911.255322] [UFW BLOCK] IN=eth0 OUT= MAC=04:01:4b:83:f5:01:84:b5:9c:f9:18:30:08:00 SRC=198.103.184.76 DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=44 ID=20968 PROTO=TCP SPT=29630 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
I have my UFW rules setup as follows:
To Action From
-- ------ ----
Anywhere DENY 89.248.171.5
22 ALLOW Anywhere
443 ALLOW Anywhere
80 ALLOW Anywhere
22 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
Thanks Mitchell Anicas for the article. It’s helpful very much; I have a question, Can I make rules to deny or allow MAC addresses ?
after i enable ufw , i cannot get sudo apt-get update to work ,it keep say could not resolve mirror digitalocean
here is my ufw status. imcoming denny all outgoing allow all
To Action From
3690 ALLOW Anywhere 9418/tcp ALLOW Anywhere 80 ALLOW Anywhere 443 ALLOW Anywhere
80 ALLOW OUT Anywhere 443 ALLOW OUT Anywhere 53 ALLOW OUT Anywhere
I have instaled wowza in my server and in step I was demanding to open the port 1935, i execute the commande “sudo ufw enable” and as a result I had no access to my ssh! How can I get back to my SSH. I need ur help please
What do I need to configure with wordpress installed?
I have followed the initial server setup for ubuntu 16.04, installed LEMP, set-up virtual hosts and installed wordpress all from digital ocean tutorials.
can you also add on how to save those rules , that is to make them persistent because I cant find it nowhere.
A useful tip:
Usually a UFW profile such as OpenSSH is created when you install the openssh-server
package. Using the already provided profile, you can restrict access to a specific subnet such as your home network’s subnet. The command is: sudo ufw allow from 192.168.0.0/24 to any app OpenSSH
. Obviously you change the subnet accordingly.
This is what it looks like in practice using only profiles:
To Action From
-- ------ ----
137,138/udp (Samba) ALLOW IN Anywhere
139,445/tcp (Samba) ALLOW IN Anywhere
80,443/tcp (Nginx Full) ALLOW IN Anywhere
3389/tcp (MySQL) ALLOW IN Anywhere
3389/udp (MySQL) ALLOW IN Anywhere
22/tcp (OpenSSH) ALLOW IN 192.168.0.0/24
137,138/udp (Samba (v6)) ALLOW IN Anywhere (v6)
139,445/tcp (Samba (v6)) ALLOW IN Anywhere (v6)
80,443/tcp (Nginx Full (v6)) ALLOW IN Anywhere (v6)
3389/tcp (MySQL (v6)) ALLOW IN Anywhere (v6)
3389/udp (MySQL (v6)) ALLOW IN Anywhere (v6)
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
Full documentation for every DigitalOcean product.
The Wave has everything you need to know about building a business, from raising funding to marketing your product.
Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter.
New accounts only. By submitting your email you agree to our Privacy Policy
Scale up as you grow — whether you're running one virtual machine or ten thousand.
Sign up and get $200 in credit for your first 60 days with DigitalOcean.*
*This promotional offer applies to new accounts only.