A basic UFW configuration for a remote Ubuntu server looks like this:
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
After enabling the firewall, do not close the current SSH session immediately—first test a new connection in a second terminal.
You can then use UFW for specific tasks:
- Allow access to a port only from a specific IP address;
- Block individual IP addresses;
- Delete rules using ufw status numbered;
- Enable logging;
- Manage IPv6.
If the server uses Docker, ufw status alone is not enough: published container ports must also be checked using docker ps and ss.
If SSH or the website stops working after UFW is enabled, first check the rule itself and the port the service is listening on. Use ufw disable only as a temporary diagnostic step.
What UFW Is and Why You Need It
Welcome!
In this article, we’ll look at one of those things that is better configured on a server from the outset than dealt with only after the first suspicious port scan.
This refers to UFW — Uncomplicated Firewall, a simplified interface for managing the firewall in Ubuntu.
The very word firewall often makes it sound as though you are about to delve into complicated network tables, chains, priorities, and endless rules. In practice, however, UFW was created precisely so that administrators would not have to work manually with lower-level Linux mechanisms every time.
The basic idea behind a firewall is quite simple: it determines which network traffic to allow and which to block.
For example, suppose we have a standard VPS running:
- SSH for administration;
- Nginx on ports 80 and 443;
- Possibly PostgreSQL;
- Some internal services;
- Docker containers.
Without a firewall, the server may listen on more ports than we ever intended to expose publicly.
This means that anyone on the internet can try to connect to them.
UFW allows you to define clear rules in advance:
- SSH — allow
- HTTP — allow
- HTTPS — allow
- PostgreSQL — do not expose publicly
- Everything else — block
We’ll follow this approach throughout the rest of the article.
But a firewall has one unpleasant characteristic: if you configure it in the wrong order, you can lock out not only an attacker but also yourself.
This is especially easy to do on a remote VPS where SSH is the only way to manage the server.
Therefore, this article will focus not just on a set of commands, but on the sequence of steps.
How UFW Relates to the Firewall in Ubuntu
UFW is not a separate firewall that runs on top of Linux independently of the system. Rather, it is a convenient interface for managing network traffic filtering rules.
Modern Ubuntu systems may use netfilter and the associated iptables/nftables infrastructure under the hood, while UFW provides simpler commands for managing them.
Instead of relatively complex low-level rules, we can enter: sudo ufw allow 22/tcp and get a clear rule: allow incoming TCP connections on port 22.
Or: sudo ufw deny 3306/tcp, that is, block incoming connections to the MySQL service on this port.
Of course, in a real-world system, allow and deny rules should not be added haphazardly.
A firewall is typically configured according to the following principle: deny incoming traffic by default, then explicitly allow only what is required.
UFW is particularly well suited to this approach.
For example, a basic policy might be:
sudo ufw default deny incoming
sudo ufw default allow outgoing
The first command denies incoming connections unless a separate rule explicitly allows them.
The second command allows outgoing connections from the server.
This is a common configuration for a VPS.
A server typically needs to:
- Download packages via apt;
- Access APIs;
- Make DNS queries;
- Obtain certificates;
- Connect to external services.
In an ideal infrastructure, the server’s outbound connections would also be restricted using allowlists, but at a basic level, setting default outgoing to allow is acceptable.
Incoming connections, however, should be controlled differently—and more strictly.
You can think of UFW as a security guard at a building entrance.
It does not need to know what is happening inside the application, database, or Nginx.
Its task is simpler: “Which port is the traffic arriving on? Where is it coming from? Is there a rule that allows it?”
If there is no such rule, the traffic is blocked.
The most important rule: allow SSH before enabling the firewall
This is the most important part of the entire article.
If you are working with a remote VPS over SSH, do not enable UFW until you have allowed SSH access.
This is neither a formality nor an excessive precaution. To keep the saying “remote firewall configuration means a long journey ahead” from becoming a reality, you need to prepare.
Consider the following scenario.
You are connected to the server: ssh [email protected]
You then run:
sudo ufw default deny incoming
sudo ufw enable
But you have not added a rule to allow SSH.
The current SSH session may remain active for a while because the connection has already been established.
However, a new connection attempt may fail because the server simply stops accepting your connections on port 22.
This creates a rather amusing but unpleasant situation: the firewall works perfectly—so perfectly that it even protects the server from its administrator.
If your provider offers a web console, VNC, or rescue mode, you can usually resolve the issue.
If not, you will need to contact support or restore access another way.
Therefore, the correct sequence is always as follows:
- Determine how you can connect to the server if you lock yourself out;
- Check which port SSH uses.
- Allow that port in UFW.
- Only then enable the firewall.
- Do not close the current SSH session immediately.
- Open a second connection and verify that SSH is working.
For standard SSH on port 22, you can enable the predefined profile: sudo ufw allow OpenSSH
Or explicitly: sudo ufw allow 22/tcp
Both options accomplish the same task.
You can check the rule before enabling the firewall: sudo ufw status
If UFW is currently disabled, we will see something like: Status: inactive
However, the rules themselves may already have been added.
If SSH is running not on the standard port 22 but, for example, on 2222, then that is the port you need to allow: sudo ufw allow 2222/tcp
You can determine the current listening port, for example, as follows: sudo ss -lntp | grep ssh or check the SSH configuration: sudo grep -i "^Port" /etc/ssh/sshd_config
If the Port directive is not explicitly set, the default port 22 is usually used.
Here is another useful practical tip: do not close the current SSH session immediately after running ufw enable.
It is best to open a second terminal and try connecting again.
For example: ssh [email protected]
If the second connection succeeds, the SSH rule is working.
If it fails, the first session is still open, giving us a chance to fix the firewall without further trouble.
Checking UFW and Its Current Configuration
Now that we understand how it works, we can move on to the server itself.
Before adding any rules, it is useful to determine two things:
- Whether UFW is installed at all;
- Its current status.
We will also check IPv6, because securing only IPv4 and forgetting about the other network stack is not a good idea.
Install UFW if necessary
UFW is often already installed on Ubuntu, but it is still worth checking. Let’s check: ufw --version
If the command runs successfully and displays the version, everything is fine.
If we get something like: command not found, install the package:
sudo apt update
sudo apt install -y ufw
After that, check again: ufw --version
Now let’s check the current status: sudo ufw status
On a newly provisioned server, it is perfectly normal to see: Status: inactive
This means that UFW is installed, but traffic filtering through it has not yet been enabled.
Important: inactive does not indicate an error.
At this stage, we should not rush to run ufw enable, because the SSH rule still needs to be carefully reviewed and configured.
If UFW is already enabled, you will see something like: Status: active
Existing rules are listed below.
For example:
In this case, do not immediately add duplicate rules.
First, it is best to view the full configuration: sudo ufw status verbose
This command also displays the default policies and logging settings.
For example: Default: deny (incoming), allow (outgoing), disabled (routed)
This is a sensible model for a typical VPS: all incoming traffic is blocked, while required services are allowed through individual rules.
Checking IPv6 Status and Support
Now let’s take a look at IPv6.
UFW can create rules for both IPv4 and IPv6 when IPv6 support is enabled. Let’s check the file: sudo nano /etc/default/ufw
We are interested in the following line: IPV6=yes
If specified: IPV6=yes
UFW will also apply the rules to IPv6 traffic.
If it is set to: IPV6=no
UFW filtering is disabled for IPv6.
Why is this important?
Suppose the server has two public addresses:
- IPv4 → 203.0.113.10
- IPv6 → 2001:db8::10
You configured UFW only for IPv4 and believe you have closed an unnecessary port.
However, if the service is also listening on IPv6, it may still be accessible through the second address.
Therefore, if the VPS actually uses IPv6, it is best not to leave it outside the firewall rules.
After modifying /etc/default/ufw, you will need to reload the UFW configuration.
At this stage, however, you do not need to change anything; simply check the current value.
Additionally, let’s check whether the server has any IPv6 addresses: ip -6 addr
If you see only local-use addresses, IPv6 may not actually be in use externally.
If a global address is present, however, you should account for it when configuring the firewall.
You can also view the current rules in more detail: sudo ufw status verbose
If UFW is active and IPv6 is enabled, rules are often displayed in two versions:
This is a good sign: a single rule covers both IP stacks.
Let’s move on.
Configuring Basic Rules Without Losing SSH Access
We have already checked UFW, reviewed its current status, and confirmed that IPv6 has not been overlooked.
Now we can move on to the most important step: adding the basic rules and enabling the firewall without losing access to the server.
The order of operations is critical here.
First, allow SSH. Then open the web ports. Only after that should you enable UFW.
Allow SSH
If SSH is running on the default port 22, the simplest option is: sudo ufw allow OpenSSH
UFW uses the OpenSSH application profile, which typically corresponds to TCP port 22. You can check the available profiles as follows: sudo ufw app list
Expect output similar to the following:
Available applications: OpenSSH
You can also allow SSH directly by specifying the port number: sudo ufw allow 22/tcp
The result is effectively the same.
If SSH is configured to use a non-standard port, such as 2222, you must allow that specific port: sudo ufw allow 2222/tcp
Before enabling UFW, it is a good idea to verify the added rule: sudo ufw status
If the firewall is not yet enabled, the status may still show:
Status: inactive
This is normal. The rule has already been saved and will take effect once UFW is enabled.
Most importantly, do not run ufw enable until SSH access has been allowed.
Allowing HTTP and HTTPS
Now, let’s allow the ports required by a standard web server.
HTTP uses TCP port 80: sudo ufw allow 80/tcp
HTTPS — TCP port 443: sudo ufw allow 443/tcp
You can also use a predefined Nginx application profile if one is installed.
Let’s check: sudo ufw app list
Available profiles may include:
Nginx Full
Nginx HTTP
Nginx HTTPS
For example:
sudo ufw allow "Nginx Full" typically opens both 80 and 443. However, explicit rules are clearer for learning purposes:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
This makes it immediately clear which ports are being allowed.
There is no need to allow every service on the server.
For example, if PostgreSQL is running locally only, port 5432 does not need to be exposed externally.
The same applies to local application ports such as:
8000
3000
8080
If a service is behind Nginx and listens only on 127.0.0.1, there is no reason to open the corresponding port in UFW.
For a typical VPS, the basic rule set may look like this:
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
Before enabling it, let’s check once more: sudo ufw status
Enable UFW and verify the result
SSH is now allowed, and HTTP and HTTPS are configured as well. You can enable the firewall: sudo ufw enable
UFW will warn you that enabling the firewall may affect existing SSH connections. If the SSH rule was added correctly, confirm: y
After that, check the status: sudo ufw status verbose
You should see something like this:
If you used the OpenSSH profile instead of 22/tcp, the table may display the profile name.
However, the verification does not end there.
Do not close the current SSH session.
Open a second terminal window and try connecting to the VPS again: ssh [email protected]
If a new connection can be established, SSH is indeed not blocked.
You can then check the web ports.
For example: curl -I http://203.0.113.10 or, if the domain is already connected: curl -I https://example.com
If Nginx is running, you should receive the expected HTTP response.
You can also check which processes are listening on network ports: sudo ss -lntp
This is a useful check because UFW does not start services itself.
For example, the rule: sudo ufw allow 443/tcp only allows traffic.
If Nginx is not listening on port 443, the site will not automatically become available over HTTPS.
Conversely, just because an application is listening on a port does not mean that the port must be exposed externally.
The basic protection is now in place: inbound connections are controlled by UFW, administrative access remains available, and only the required web ports are exposed.
Next, we will move on to more targeted rules—for example, allowing access to a specific port only from a particular IP address and seeing how to block individual sources.
Restricting Access by IP Address
Allowing a port only for a specific IP address
Suppose you need to allow SSH access only from: 198.51.100.25
The rule then looks like this:
sudo ufw allow from 198.51.100.25 to any port 22 proto tcp Here, we specify all of the following:
- Source: 198.51.100.25;
- Port: 22;
- Protocol: TCP.
Let’s check: sudo ufw status
You will see a rule similar to this:
However, there is an important caveat.
If we previously ran: sudo ufw allow OpenSSH or: sudo ufw allow 22/tcp
SSH is still allowed from any IP address.
In other words, adding a more restrictive rule does not override the broader rule.
If the goal is to allow SSH access from only one IP address, you must remove the old rule.
Before doing so, make sure that your IP address is indeed static.
If your ISP assigns a dynamic IP address, the rule may work today, but tomorrow you may be assigned a different address and, as noted earlier, lock yourself out.
Therefore, restricting SSH access to a single IP address is practical only when the source address is predictable.
You can do the same for other ports.
For example, allow PostgreSQL access only from an external server:
sudo ufw allow from 198.51.100.25 to any port 5432 proto tcp Or the management interface:
sudo ufw allow from 198.51.100.25 to any port 8080 proto tcp However, you should expose such services to the internet only when absolutely necessary.
Blocking a Specific IP Address
The reverse approach works as well.
To block all incoming traffic from a specific address: sudo ufw deny from 198.51.100.50
For a specific port: sudo ufw deny from 198.51.100.50 to any port 22 proto tcp
This can be useful if a particular source repeatedly attempts to access a specific service.
However, you should not turn UFW into an endless list of random IP addresses collected from logs.
Internet-wide server scanning is common, and attackers can easily change their IP addresses.
It is much better to first configure the default policy correctly: deny incoming, and then allow only the services that are actually required.
Managing UFW Rules
Over time, a firewall rarely remains as neatly configured as it was on the day it was first set up.
You may open a port for testing, change the SSH port, or temporarily allow an IP address, then forget to remove the rule.
That is why it is important not only to know how to add rules, but also how to manage them properly.
Viewing rules by number
Standard view: sudo ufw status
This displays the current configuration, but it is more convenient to use rule numbers when deleting rules.
Run: sudo ufw status numbered
For example:
You can now refer to a specific rule by number.
This is especially useful when there are several similar entries.
Removing Unnecessary Rules
Suppose test port 8080 is no longer needed.
Delete rule number 4: sudo ufw delete 4
UFW will ask for confirmation.
After removing it, check again: sudo ufw status numbered
Alternatively, you can remove the rule in the same way it was added.
For example: sudo ufw delete allow 443/tcp or sudo ufw delete deny from 198.51.100.50
However, using rule numbers is usually clearer.
One detail to keep in mind is that after a rule is deleted, the numbers of the remaining entries may change.
Therefore, if you plan to delete several rules in succession, it is best to run the following command again each time: sudo ufw status numbered, rather than relying on the previous numbering.
Enabling Logging
Once the firewall is running, you may want to see exactly what it is blocking.
To do this, enable logging: sudo ufw logging on
You can check the status using: sudo ufw status verbose
This will display information about logging.
By default, UFW logs events through the system journal, while Ubuntu also commonly uses the following file: /var/log/ufw.log
You can view the latest entries as follows: sudo tail -n 50 /var/log/ufw.log
To monitor in real time: sudo tail -f /var/log/ufw.log
The logs can show:
- Blocked packet;
- Source IP address;
- Destination IP address;
- Port;
- Protocol;
- Interface.
This is useful when you are sure that a service is running, but the client cannot connect to it.
You can then check whether the request is failing to reach the service at all or is being blocked by UFW.
If too many logs are generated, you can adjust the logging level: sudo ufw logging low
The available levels include:
off
low
medium
high
full
For a typical VPS, low is usually sufficient.
The higher the level, the more entries are generated, which means the logs may grow faster.
UFW can now not only allow access to the required services, but also restrict access by source, remove outdated rules, and help with troubleshooting through logs.
Two easily overlooked topics remain to be covered separately: IPv6 and Docker.
IPv6 and UFW
Verify That IPv6 Is Also Filtered
Let’s start with the UFW configuration: sudo grep "^IPV6=" /etc/default/ufw
Expected: IPV6=yes
If so, UFW will create rules for both IPv4 and IPv6.
You can check whether the server has any IPv6 addresses as follows: ip -6 addr
This is especially important if the server uses a globally routable IPv6 address.
Now let’s view the rules: sudo ufw status
When IPv6 support is enabled, you may see pairs such as:
This means that the rules are applied to both IP stacks.
If, however, IPV6=no and the server actually uses IPv6, it is best to first change it to: IPV6=yes, and then apply the UFW settings.
After making changes: sudo ufw reload
If the configuration was changed on a running server, check the firewall again after rebooting: sudo ufw status verbose
The point is simple: if the service is accessible over IPv6, the firewall must also account for IPv6.
Otherwise, you may encounter an unexpected situation where a port is closed over IPv4 but remains accessible over IPv6.
UFW and Docker: An Important Caveat
This is where one of the best-known UFW pitfalls comes into play.
Suppose we are certain that we have exposed only the following ports:
- 22
- 80
- 443
Then start the container: docker run -p 8080:80 nginx
It would be reasonable to expect UFW to block external access to port 8080, since we did not add an allow rule for it.
However, Docker handles network rules somewhat differently.
Why Published Docker Ports Can Bypass Expected UFW Rules
Docker automatically adds netfilter/iptables rules for NAT and traffic forwarding. As a result, traffic to published container ports may be processed before it passes through the UFW chains that the administrator expects it to.
Therefore, the situation may look like this: sudo ufw status only shows:
but the Docker container published using: -p 8080:80 is still accessible externally.
Ultimately, Docker itself intervenes in network traffic processing and creates its own rules.
This is especially important to understand if you run Docker on a public VPS and rely on UFW as your only traffic filter.
You can check the containers’ published ports as follows: docker ps
For example: 0.0.0.0:8080->80/tcp
The key point here is: 0.0.0.0:8080
This means that Docker listens on the port on all of the server’s IPv4 interfaces.
If the container should be accessible only locally, it is safer to bind it to the loopback interface: docker run -p 127.0.0.1:8080:80 nginx
The service will then be accessible only from the VPS itself.
This approach is particularly useful for a container behind Nginx: Nginx → 127.0.0.1:8080 → Docker container
There is no need to publish port 8080 externally at all.
How to Use UFW and Docker More Securely
The key rule here is— do not rely solely on the ufw status output, if Docker is running on the server.
Always verify which ports are actually published: docker ps and which ports the system is listening on: sudo ss -lntp
Pay particular attention to the bind address.
For example: 0.0.0.0:8080 means access via all IPv4 interfaces, while: 127.0.0.1:8080 — local access only.
For most applications behind a reverse proxy, the second option is more secure.
If a container genuinely needs to be directly accessible from the internet, its access rules should be planned separately, taking Docker networking and the DOCKER-USER chain into account.
However, for a typical VPS, a simpler approach is often sufficient:
- Do not expose unnecessary container ports externally;
- Bind internal services to 127.0.0.1;
- Expose only Nginx on ports 80 and 443;
- Separately check the actual listening ports using ss and docker ps.
This is where it is especially important to remember that a firewall is more than what appears in ufw status.
If Docker is installed on the server, the actual network exposure may be broader than UFW alone would suggest.
If Something Stops Working After Enabling UFW
Even with careful firewall configuration, things can sometimes go wrong.
The key in this situation is not to start deleting every rule indiscriminately. It is far more useful to first determine what exactly has stopped working and at what level.
If you cannot connect via SSH, check the access rules for the administrative port.
If the website becomes unavailable, check ports 80 and 443, and also make sure that Nginx itself is listening on those ports.
Only temporarily disable UFW if you urgently need to restore access to the server.
SSH No Longer Connects
If a new SSH session cannot be established after enabling UFW, first check whether the required port is allowed.
If the old SSH session is still active, run: sudo ufw status numbered
For standard SSH, you should see a rule similar to this: 22/tcp ALLOW IN Anywhere or OpenSSH ALLOW IN Anywhere
If a non-standard port is used, for example: 2222, check that specific port: sudo ss -lntp | grep ssh
If SSH is listening on port 2222 but only port 22 is open in UFW, you have found the cause.
Add the correct rule: sudo ufw allow 2222/tcp and try connecting again from the second terminal.
If SSH access is restricted to a specific IP address:
sudo ufw allow from 198.51.100.25 to any port 22 proto tcp you should also check your current public IP address.
If it has changed, UFW will correctly block the new connection.
This is why restricting SSH access by IP address is practical only when the source IP is stable.
If the current session has already been lost, use one of the alternative access methods provided by your hosting provider:
- Web console;
- VNC;
- Serial console;
- Rescue mode.
You can use it to correct the rule and restore SSH access.
The website is inaccessible over HTTP or HTTPS
If the website becomes inaccessible after configuring UFW, first check the allowed web ports: sudo ufw status
The following ports must be allowed:
80/tcp
443/tcp
If these rules are missing:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
After that: sudo ufw reload
However, it is important not to confuse the firewall with the web server itself.
UFW may allow traffic on port 443, but HTTPS will still not work if Nginx is not running or is not listening on that port.
Check: sudo ss -lntp | grep -E ':80|:443' and sudo systemctl status nginx --no-pager
If ports 80 or 443 do not appear in the ss output, the problem is not with UFW.
For HTTP, you can also run a local check: curl -I http://127.0.0.1
If the website responds locally but is inaccessible externally, the firewall is one of the first things to investigate.
If it does not respond even locally, investigate Nginx or the application itself.
When to Temporarily Disable UFW
Sometimes you need to quickly test a hypothesis: is UFW actually blocking the connection?
In this case, the firewall can be temporarily disabled: sudo ufw disable
Immediately afterward, retry the connection that was failing.
If the service suddenly starts working, the problem was indeed caused by the UFW rules.
However, you should not leave the firewall disabled simply because “everything works” that way.
It is better to identify the specific rule causing the problem.
After applying the fix, enable UFW again: sudo ufw enable and check its status: sudo ufw status verbose
In other words, ufw disable is primarily a diagnostic tool or a temporary emergency measure.
If something stops working after you enable the firewall, work through the following troubleshooting questions:
- Is the service running?
- Is the required port listening?
- Does UFW allow traffic on that port?
- Is the rule restricted to the wrong IP address?
- Is Docker changing the expected network behavior?
This approach usually helps identify the cause fairly quickly.
Conclusion
UFW is one of those tools that seems simple—until you enable the firewall too soon and lock yourself out of SSH.
That is why the key to configuring it lies not in the number of commands, but in performing the steps in the correct order.
First, verify SSH access and allow administrative access. Next, allow only the required services, enable UFW, and be sure to test a new connection in a separate SSH session.
You can then restrict access by IP address, remove unnecessary rules, enable logging, and account for IPv6.
Docker and other software that “interferes” with traffic and creates its own rules requires special attention. Published container ports may not behave as expected based solely on ufw status, so on Docker hosts it is always useful to also check the actual listening ports and container port bindings.
Ultimately, the standard approach for a typical VPS is quite simple: expose only what is genuinely required, keep everything else closed, and periodically check whether any new services have appeared that the firewall does not yet know about.
FAQ
Do I need to allow SSH access from all IP addresses?
Not necessarily.
If you always connect to the server from the same static IP address, you can allow SSH access only from that address:
sudo ufw allow from 198.51.100.25 to any port 22 proto tcp However, if your IP address is dynamic, this approach could eventually lock you out. Therefore, first make sure that the address is indeed static.
Which is better: ufw allow OpenSSH or ufw allow 22/tcp?
Both options work for standard SSH on port 22.
Command: sudo ufw allow OpenSSH uses a predefined UFW application profile.
A: sudo ufw allow 22/tcp specifies the port directly.
If SSH has been moved to another port, such as 2222, the predefined profile will not work without updating its configuration; it is easier to explicitly allow the required port.
Do I need to open ports for PostgreSQL, Redis, or the application’s internal port in UFW?
Only if the service genuinely needs to accept external connections.
If PostgreSQL, Redis, Gunicorn, or the Node.js application runs on the same VPS and is accessible via 127.0.0.1, there is no need to open its ports in UFW.
The fewer services exposed externally, the easier it is to control the attack surface.
Why is a port blocked in UFW, but the Docker container is still accessible?
Because Docker creates its own network rules for published ports.
For example: docker run -p 8080:80 nginx can expose port 8080 externally, regardless of how the administrator expects standard UFW rules to behave.
Therefore, on Docker hosts, you should also check:
docker ps
sudo ss -lntp
It is more convenient to bind internal container services behind a reverse proxy to 127.0.0.1.
What happens to the current SSH session after running ufw enable?
An established connection may continue to work, but you should not rely on this.
That is why, after enabling UFW, it is best not to close the current terminal, but instead to open a second SSH session and test the new connection.
If you can establish a new session, access is configured correctly.
Can UFW be completely reset?
Yes: sudo ufw reset
This command disables UFW and removes all user-defined rules.
Use it with caution: after the reset, you will need to reconfigure SSH access and all other permissions.
On a remote VPS, it is especially important to avoid losing access during reconfiguration.
Do I need to enable IPv6 in UFW if I do not use it?
If the VPS has no public IPv6 address and the IPv6 stack is not actually in use, there may be no practical difference.
However, if the server has been assigned a global IPv6 address, the firewall rules must cover it as well. Otherwise, a service may be blocked over IPv4 but remain accessible over IPv6.
You can check this using the following commands:
ip -6 addr
sudo ufw status
Is UFW Alone Enough to Protect a VPS?
No. UFW is only one layer of security.
It helps restrict network access, but it is not a substitute for:
- System updates;
- Secure SSH configuration;
- Strong keys and passwords;
- User permissions;
- Application configuration;
- Backups;
- Docker port management;
- Monitoring and logging.
A firewall reduces the attack surface, but it cannot fix a vulnerable service that is already exposed to the internet.
