UFW:(8)

💅 UFW 💅

okay so this is the ufw manual page — section 8 (UFW:(8)), dated May 2023 — and it's literally the program for managing a netfilter firewall. Bestie, it's giving “let me make firewall stuff make sense.” 🫶

💖 NAME 💖

ufw — program for managing a netfilter firewall. That's the name, no cap. ✨

🌸 DESCRIPTION 🌸

This program is for managing a Linux firewall, and its whole goal is to provide an easy-to-use interface for the user. Lowkey iconic: it's a firewall tool that actually wants you to understand it. 💅

🦋 USAGE 🦋

Here are the shapes ufw takes, bestie — copy these exactly, because syntax is main character energy:

ufw [--dry-run] enable|disable|reload

ufw [--dry-run] default allow|deny|reject [incoming|outgoing|routed]

ufw [--dry-run] logging on|off|LEVEL

ufw [--dry-run] reset

ufw [--dry-run] status [verbose|numbered]

ufw [--dry-run] show REPORT

ufw [--dry-run] [delete] [insert NUM] [prepend] allow|deny|reject|limit
[in|out] [log|log-all] [ PORT[/PROTOCOL] | APPNAME ] [comment COMMENT]

ufw [--dry-run] [rule] [delete] [insert NUM] [prepend]
allow|deny|reject|limit [in|out [on INTERFACE]] [log|log-all] [proto
PROTOCOL] [from ADDRESS [port PORT | app APPNAME ]] [to ADDRESS [port
PORT | app APPNAME ]] [comment COMMENT]

ufw [--dry-run] route [delete] [insert NUM] [prepend]
allow|deny|reject|limit [in|out on INTERFACE] [log|log-all] [proto
PROTOCOL] [from ADDRESS [port PORT | app APPNAME]] [to ADDRESS [port
PORT | app APPNAME]] [comment COMMENT]

ufw [--dry-run] [--force] delete NUM

ufw [--dry-run] app list|info|default|update

✨ OPTIONS ✨

• --version — show program's version number and exit. Cute little identity check. 🎀
• -h, --help — show help message and exit. The “bestie, explain” button. 🫶
• --dry-run — don't modify anything, just show the changes. A vibe check before the actual vibe check. 👀
• enable — reloads firewall and enables firewall on boot. Firewall wakes up and stays up. 🔥
• disable — unloads firewall and disables firewall on boot. Firewall goes night-night. 💀
• reload — reloads firewall. Like refreshing the group chat, but for rules. 🔄
• default allow|deny|reject DIRECTION — change the default policy for traffic going DIRECTION, where DIRECTION is one of incoming, outgoing or routed. Note that existing rules will have to be migrated manually when changing the default policy. See RULE SYNTAX for more on deny and reject. This is a big-main-character setting, ngl. 👑
• logging on|off|LEVEL — toggle logging. Logged packets use the LOG_KERN syslog facility. Systems configured for rsyslog support may also log to /var/log/ufw.log. Specifying a LEVEL turns logging on for the specified LEVEL. The default log level is 'low'. See LOGGING for details. Receipts, but for packets. 🧾✨
• reset — Disables and resets firewall to installation defaults. Can also give the --force option to perform the reset without confirmation. This one is giving “are you sure, bestie?” so read it twice. 💀🫶
• status — show status of firewall and ufw managed rules. Use status verbose for extra information. In the status output, Anywhere is synonymous with any, 0.0.0.0/0 (IPv4) and ::/0 (IPv6). Note that when using status, there is a subtle difference when reporting interfaces. For example, if the following rules are added:

ufw allow in on eth0 from 192.168.0.0/16
ufw allow out on eth1 to 10.0.0.0/8
ufw route allow in on eth0 out on eth1 to 10.0.0.0/8 from 192.168.0.0/16
ufw limit 2222/tcp comment 'SSH port'

then ufw status will output:

To                         Action      From
--                         ------      ----
Anywhere on eth0           ALLOW       192.168.0.0/16
10.0.0.0/8                 ALLOW OUT   Anywhere on eth1
10.0.0.0/8 on eth1         ALLOW FWD   192.168.0.0/16 on eth0
Anywhere                   LIMIT       Anywhere
# SSH port

For the input and output rules, the interface is reported relative to the firewall system as an endpoint, whereas with route rules, the interface is reported relative to the direction packets flow through the firewall. That distinction is lowkey important, iykyk. 🦋

• show REPORT — display information about the running firewall. See REPORTS. It's giving “show me the receipts.” 🧾💖
• allow ARGS — add allow rule. See RULE SYNTAX. Permission granted, periodt. ✅
• deny ARGS — add deny rule. See RULE SYNTAX. Not today, packet. ❌
• reject ARGS — add reject rule. See RULE SYNTAX. Denied, but with a reply. 💅
• limit ARGS — add limit rule. See RULE SYNTAX. Rate-limit energy. 🚦
• delete RULE|NUM — deletes the corresponding RULE. Bye-bye, rule. 🗑️✨
• insert NUM RULE — insert the corresponding RULE as rule number NUM. Cut the line, literally. 🎟️
• prepend RULE — prepend the corresponding RULE to the top of the ruleset. Front of the line, main character behavior. 👑

✨ RULE SYNTAX ✨

okay so this is the part everyone actually cares about 💅 you've got two ways to write a rule — the simple way and the full way. The simple syntax is just: the port, and optionally the protocol, that you're allowing or denying on this host. That's it. Low effort, high reward.

Both syntaxes let you slap a comment on a rule. And here's the cute bit: for existing rules, specifying a different comment updates the comment, and specifying '' removes the comment. But heads up — insert and prepend can not be used to update the comment. No exceptions, bestie.

---

🌸 Simple syntax examples

Example rules using the simple syntax:

ufw allow 53

This one allows tcp and udp port 53 to any address on this host. Both. At once. Overachiever ✨

Wanna be specific about the protocol? Just append /protocol to the port. Like:

ufw allow 25/tcp

This will allow tcp port 25 to any address on this host. And ufw will also check /etc/services for the port and protocol if you're specifying a service by name. Eg:

ufw allow smtp

ufw supports both ingress and egress filtering, and you can optionally specify a direction — either in or out — for incoming or outgoing traffic. If you don't supply a direction, the rule applies to incoming traffic. Default behaviour, no cap. Eg:

ufw allow in http
ufw reject out smtp
ufw reject telnet comment 'telnet is unencrypted'

---

🦋 The full syntax (she's thorough)

You can also use a fuller syntax where you specify the source and destination addresses and ports. This syntax is loosely based on OpenBSD's PF syntax. For example:

ufw deny proto tcp to any port 80

This denies all traffic to tcp port 80 on this host. Another one:

ufw deny proto tcp from 10.0.0.0/8 to 192.168.0.1 port 25

This denies all traffic from the RFC1918 Class A network to tcp port 25 with the address 192.168.0.1.

ufw deny proto tcp from 2001:db8::/32 to any port 25

This denies all traffic from the IPv6 2001:db8::/32 to tcp port 25 on this host. ⚠️ IPv6 must be enabled in /etc/default/ufw for IPv6 firewalling to work — don't come crying to me if it doesn't.

ufw deny in on eth0 to 224.0.0.1 proto igmp

This denies all igmp traffic to 224.0.0.1 on the eth0 interface.

ufw allow in on eth0 to 192.168.0.1 proto gre

This allows all gre traffic to 192.168.0.1 on the eth0 interface.

ufw allow proto tcp from any to any port 80,443,8080:8090 comment 'web app'

The above allows all traffic to tcp ports 80, 443 and 8080-8090 inclusive, and adds a comment for the rule. 🌈

Important port-list tea ☕: when you specify multiple ports, the ports list must be numeric, cannot contain spaces, and must be modified as a whole. Eg, in the above example you cannot later try to delete just the 443 port. Also you cannot specify more than 15 ports (ranges count as 2 ports, so the port count in the above example is 4). Math is mathing.

---

💜 Protocols, and which ones behave

ufw supports several different protocols. These following ones are valid in any rule and enabled when the protocol is not specified:

• tcp
• udp

The following have certain restrictions and are not enabled when the protocol is not specified:

• ah — valid without port number
• esp — valid without port number
• gre — valid without port number
• vrrp — valid without port number
• ipv6 — valid for IPv4 addresses and without port number
• igmp — valid for IPv4 addresses and without port number

---

🎀 Route rules (for traffic just passing through)

Rules for traffic that is not destined for the host itself but instead should be routed/forwarded through the firewall — those need the route keyword before the rule. (Routing rules differ significantly from PF syntax and instead take into account netfilter FORWARD chain conventions. iykyk.) For example:

ufw route allow in on eth1 out on eth2

This allows all traffic routed to eth2 and coming in on eth1 to traverse the firewall.

ufw route allow in on eth0 out on eth1 to 12.34.45.67 port 80 proto tcp

This rule allows any packets coming in on eth0 to traverse the firewall out on eth1 to tcp port 80 on 12.34.45.67.

Fr fr though: in addition to routing rules and policy, you must also set up IP forwarding. This may be done by setting the following in /etc/ufw/sysctl.conf:

net/ipv4/ip_forward=1
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1

then restarting the firewall:

ufw disable
ufw enable

Be aware that setting kernel tunables is operating system specific and ufw sysctl settings may be overridden. See the sysctl manual page for details. 🔍

---

🔥 Rate limiting (aka anti-brute-force era)

ufw supports connection rate limiting, which is genuinely so useful for protecting against brute-force login attacks. When a limit rule is used, ufw will normally allow the connection but will deny connections if an IP address attempts to initiate 6 or more connections within 30 seconds. See http://www.debian-administration.org/articles/187 for details. Typical usage is:

ufw limit ssh/tcp

---

💀 reject vs deny

Sometimes it's desirable to let the sender know when traffic is being denied, rather than simply ignoring it. In these cases, use reject instead of deny. For example:

ufw reject auth

---

🧚 Interface-specific rules

By default, ufw applies rules to all available interfaces. To limit that, specify DIRECTION on INTERFACE, where DIRECTION is one of in or out. (Interface aliases are not supported — sorry babe.) For example, to allow all new incoming http connections on eth0, use:

ufw allow in on eth0 to any port 80 proto tcp

---

🗑️ Deleting rules (the breakup)

To delete a rule, simply prefix the original rule with delete — with or without the rule comment. For example, if the original rule was:

ufw deny 80/tcp

Use this to delete it:

ufw delete deny 80/tcp

You may also specify the rule by NUM, as seen in the status numbered output. For example, if you want to delete rule number 3, use:

ufw delete 3

Careful, babe 💅 If you have IPv6 enabled and you're deleting a generic rule that applies to both IPv4 and IPv6 (eg ufw allow 22/tcp), deleting by rule number will delete only the specified rule. To delete both with one command, prefix the original rule with delete.

---

👑 Inserting and prepending

To insert a rule, specify the new rule as normal, but prefix the rule with the rule number to insert. For example, if you have four rules, and you want to insert a new rule as rule number three, use:

ufw insert 3 deny to any port 22 from 10.0.0.135 proto tcp

Similarly, to add a rule before all other rules matching the rule's IP type, use the prepend rule:

ufw prepend deny from 1.2.3.4

This is particularly useful for dynamic firewalls as found in an IPS. Importantly: if the specified rule is an IPv4 rule, it will be prepended before all other IPv4 rules. If it's an IPv6 rule, it will be prepended before any IPv6 rules. 💫

To see a list of numbered rules, use:

ufw status numbered

---

🍓 Per-rule logging

ufw supports per-rule logging. By default, no logging is performed when a packet matches a rule. Specifying log will log all new connections matching the rule, and log-all will log all packets matching the rule. For example, to allow and log all new ssh connections, use:

ufw allow log 22/tcp

See LOGGING for more information on logging.

---

🌟 EXAMPLES 🌟

Deny all access to port 53:

ufw deny 53

Allow all access to tcp port 80:

ufw allow 80/tcp

Allow all access from RFC1918 networks to this host:

ufw allow from 10.0.0.0/8
ufw allow from 172.16.0.0/12
ufw allow from 192.168.0.0/16

Deny access to udp port 514 from host 1.2.3.4:

ufw deny proto udp from 1.2.3.4 to any port 514

Allow access to udp 1.2.3.4 port 5469 from 1.2.3.5 port 5469:

ufw allow proto udp from 1.2.3.5 port 5469 to 1.2.3.4 port 5469

---

🌸 REMOTE MANAGEMENT 🌸

okay this one's important if you're doing this over ssh — read it, bestie, I'm literally begging 🙈

When running ufw enable or starting ufw via its initscript, ufw will flush its chains. This is required so ufw can maintain a consistent state, but it may drop existing connections (eg ssh). ufw does support adding rules before enabling the firewall, so administrators can do:

ufw allow proto tcp from any to any port 22

before running ufw enable. The rules will still be flushed, but the ssh port will be open after enabling the firewall. 🫶

Please note that once ufw is enabled, ufw will not flush the chains when adding or removing rules (but it will when modifying a rule or changing the default policy). By default, ufw will prompt when enabling the firewall while running under ssh. This can be disabled by using ufw --force enable.

---

🎀 APPLICATION INTEGRATION 🎀

ufw supports application integration by reading profiles located in /etc/ufw/applications.d. To list the names of application profiles known to ufw, use:

ufw app list

Users can specify an application name when adding a rule (quoting any profile names with spaces). For example, when using the simple syntax, users can use:

ufw allow <name>

Or for the extended syntax:

ufw allow from 192.168.0.0/16 to any app <name>

Do not specify the protocol with either syntax, and with the extended syntax, use app in place of the port clause. That's the whole vibe.

Details on the firewall profile for a given application can be seen with:

ufw app info <name>

where '<name>' is one of the applications seen with the app list command. Users may also specify all to see the profiles for all known applications. 👀

---

💜 The profile format

Syntax for the application profiles is a simple .INI format:

[<name>]
title=<title>
description=<description>
ports=<ports>

The ports field may specify a '|'-separated list of ports/protocols where the protocol is optional. A comma-separated list or a range (specified with 'start:end') may also be used to specify multiple ports, in which case the protocol is required. For example:

[SomeService]
title=Some title
description=Some description
ports=12/udp|34|56,78:90/tcp

In the above example, 'SomeService' may be used in app rules and it specifies UDP port 12, TCP and UDP on port 34 and TCP ports 56 and 78-90 inclusive. Slay. ✨

---

🦋 Updating profiles

After creating or editing an application profile, users can run:

ufw app update <name>

This command will automatically update the firewall with updated profile information. If you specify 'all' for name, then all the profiles will be updated. To update a profile and add a new rule to the firewall automatically, users can run:

ufw app update --add-new <name>

The behavior of the update --add-new command can be configured using:

ufw app default <policy>

The default application policy is skip, which means that the update --add-new command will do nothing. Users may also specify a policy of allow or deny so the update --add-new command may automatically update the firewall.

WARNING 🚨 it may be a security risk to use a default allow policy for application profiles. Carefully consider the security ramifications before using a default allow policy. I'm serious, bestie — don't just vibe your way into that one. 💀

📜 LOGGING 📜

okay so bestie, ufw supports multiple logging levels, and if you don’t specify a loglevel it defaults to low. You set it like this:

ufw logging LEVEL

LEVEL may be off, low, medium, high and full. Here’s the definition tea ☕:

• off — disables ufw managed logging
• low — logs all blocked packets not matching the defined policy (with rate limiting), as well as packets matching logged rules
• medium — log level low, plus all allowed packets not matching the defined policy, all INVALID packets, and all new connections. All logging is done with rate limiting.
• high — log level medium (without rate limiting), plus all packets with rate limiting
• full — log level high without rate limiting

Log levels above medium generate a LOT of logging output, and may quickly fill up your disk. Log level medium may generate a lot of logging output on a busy system. 😭

Also, specifying on simply enables logging at log level low if logging is currently not enabled. cute and simple 💅

---

📊 REPORTS 📊

The following reports are supported. Each one is based on the live system, and with the exception of the listening report, is in raw iptables format:

raw
builtins
before-rules
user-rules
after-rules
logging-rules
listening
added

The raw report shows the complete firewall, while the others show a subset of what is in the raw report. very “full picture vs. close-up” energy ✨

The listening report will display the ports on the live system in the listening state for tcp and the open state for udp, along with the address of the interface and the executable listening on the port. An * is used in place of the address of the interface when the executable is bound to all interfaces on that port. Following this information is a list of rules which may affect connections on this port. The rules are listed in the order they are evaluated by the kernel, and the first match wins. Please note that the default policy is not listed and tcp6 and udp6 are shown only if IPV6 is enabled.

The added report displays the list of rules as they were added on the command-line. This report does not show the status of the running firewall (use ufw status instead). Because rules are normalized by ufw, rules may look different than the originally added rule. Also, ufw does not record command ordering, so an equivalent ordering is used which lists IPv6-only rules after other rules. iykyk 🫶

---

🧠 NOTES 🧠

On installation, ufw is disabled with a default incoming policy of deny, a default forward policy of deny, and a default outgoing policy of allow, with stateful tracking for NEW connections for incoming and forwarded connections. In addition to the above, a default ruleset is put in place that does the following:

• DROP packets with RH0 headers
• DROP INVALID packets
• ACCEPT certain icmp packets (INPUT and FORWARD): destination-unreachable, source-quench, time-exceeded, parameter-problem, and echo-request for IPv4. destination-unreachable, packet-too-big, time-exceeded, parameter-problem, and echo-request for IPv6.
• ACCEPT icmpv6 packets for stateless autoconfiguration (INPUT)
• ACCEPT ping replies from IPv6 link-local (ffe8::/10) addresses (INPUT)
• ACCEPT DHCP client traffic (INPUT)
• DROP non-local traffic (INPUT)
• ACCEPT mDNS (zeroconf/bonjour/avahi 224.0.0.251 for IPv4 and ff02::fb for IPv6) for service discovery (INPUT)
• ACCEPT UPnP (239.255.255.250 for IPv4 and ff02::f for IPv6) for service discovery (INPUT)

Rule ordering is important and the first match wins. Therefore when adding rules, add the more specific rules first with more general rules later. no cap, this is the whole game 🔥

ufw is not intended to provide complete firewall functionality via its command interface, but instead provides an easy way to add or remove simple rules.

The status command shows basic information about the state of the firewall, as well as rules managed via the ufw command. It does not show rules from the rules files in /etc/ufw. To see the complete state of the firewall, users can ufw show raw. This displays the filter, nat, mangle and raw tables using:

iptables -n -L -v -x -t <table>
ip6tables -n -L -v -x -t <table>

See the iptables and ip6tables documentation for more details.

If the default policy is set to REJECT, ufw may interfere with rules added outside of the ufw framework. See README for details. 🫣

IPV6 is allowed by default. To change this behavior to only accept IPv6 traffic on the loopback interface, set IPV6 to no in /etc/default/ufw and reload ufw. When IPv6 is enabled, you may specify rules in the same way as for IPv4 rules, and they will be displayed with ufw status. Rules that match both IPv4 and IPv6 addresses apply to both IP versions. For example, when IPv6 is enabled, the following rule will allow access to port 22 for both IPv4 and IPv6 traffic:

ufw allow 22

IPv6 over IPv4 tunnels and 6to4 are supported by using the ipv6 protocol (41). This protocol can only be used with the full syntax. For example:

ufw allow to 10.0.0.1 proto ipv6
ufw allow to 10.0.0.1 from 10.4.0.0/16 proto ipv6

IPSec is supported by using the esp (50) and ah (51) protocols. These protocols can only be used with the full syntax. For example:

ufw allow to 10.0.0.1 proto esp
ufw allow to 10.0.0.1 from 10.4.0.0/16 proto esp
ufw allow to 10.0.0.1 proto ah
ufw allow to 10.0.0.1 from 10.4.0.0/16 proto ah

keepalived is supported by using the vrrp (112) protocol. This protocol can only be used with the full syntax. For example:

ufw allow to 224.0.0.0/24 from 10.0.0.1 proto vrrp

In addition to the command-line interface, ufw also provides a framework which allows administrators to modify default behavior as well as take full advantage of netfilter. See the ufw-framework manual page for more information. ✨

---

👀 SEE ALSO 👀

• ufw-framework(8)
• iptables(8)
• ip6tables(8)
• iptables-restore(8)
• ip6tables-restore(8)
• sysctl(8)
• sysctl.conf(5)

---

💖 AUTHOR 💖

ufw is Copyright 2008-2023, Canonical Ltd.

---

Cute sign-off bestie: this page is source/version UFW:(8), dated May 2023 — both accounted for, no footer line copy-paste needed 💅✨🌸