A Parrot Linux firewall is one of those things that is easy to assume is already taken care of. In practice, a fresh install opens very few ports, but as soon as you start a web server for a lab target, enable SSH to reach the machine from another box, or run Docker, the picture changes. This guide explains the two realistic ways to manage a firewall on Parrot OS: nftables, the native packet filter in modern Debian kernels, and ufw, the simpler front end many people know from Ubuntu. You will learn how to see what is listening, write a sensible default ruleset with either tool, and avoid the common mistake of running both at once.
How the Parrot Linux firewall stack fits together
Everything here ends up in the kernel’s netfilter subsystem. What differs is the layer you talk to:
- nftables is the current framework. The
nftcommand loads rules directly, and thenftables.serviceunit restores a ruleset from/etc/nftables.confat boot. Debian 13, which Parrot 7.4 is based on, ships it by default. - iptables is the legacy command. On current Debian-based systems the
iptablesbinary is usually a compatibility shim (iptables-nft) that translates old-style rules into nftables underneath. You will still see it used by scripts and by some tools. - ufw (Uncomplicated Firewall) is a wrapper that generates iptables rules from short commands like
ufw allow 22. It also has a graphical front end,gufw.
Because all three write into the same kernel tables, mixing them produces confusing results: a rule you added with nft can be silently bypassed by a chain ufw created, and vice versa. Pick one approach per machine.
Step 1: See what is actually exposed
Before writing rules, find out which services are listening for connections from the network:
sudo ss -tulpnLook at the Local Address:Port column. Anything bound to 0.0.0.0 or [::] accepts connections from any interface; anything on 127.0.0.1 or [::1] is local only and does not need a firewall rule. On a default Parrot desktop you will typically see very little here. Services such as sshd are installed but not necessarily enabled; check with:
systemctl is-enabled ssh
systemctl is-active sshNext, check whether a firewall is already present and what it currently contains:
dpkg -l nftables ufw iptables 2>/dev/null | grep '^ii'
sudo nft list ruleset
systemctl status nftables ufw --no-pagerAn empty output from nft list ruleset means no rules are loaded and the default kernel policy of accepting everything applies. That is fine on a trusted home network with nothing listening, but not where you want to be on shared Wi-Fi.
Option A: A clean nftables ruleset
If nftables is not installed, add it and make sure the service is set to start at boot:
sudo apt update
sudo apt install nftables
sudo systemctl enable nftablesNow write a ruleset. The one below is a reasonable workstation baseline: allow loopback and established connections, allow ICMP so that ping and path discovery work, allow SSH, and drop everything else that arrives unsolicited. Save it as /etc/nftables.conf (back up the existing file first with sudo cp /etc/nftables.conf /etc/nftables.conf.bak).
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# Local traffic and replies to connections we started
iif lo accept
ct state established,related accept
ct state invalid drop
# Diagnostics
ip protocol icmp accept
ip6 nexthdr icmpv6 accept
# Services you run on this machine
tcp dport 22 accept comment "SSH"
# Log a sample of what gets dropped
limit rate 5/minute log prefix "nft-drop: " counter
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}The forward chain only matters if the machine routes traffic for others (for example as a VM host); dropping it by default is the safe choice. Validate the syntax without loading it, then load it:
sudo nft -c -f /etc/nftables.conf
sudo nft -f /etc/nftables.conf
sudo nft list rulesetIf you are connected over SSH while doing this, keep a second terminal open and test the new connection before closing the old one. Because the service is enabled, the file is reloaded on every boot.
Adding and removing rules without editing the file
For quick, temporary changes, add rules live and then persist them if you want to keep them:
# Allow a lab web server on port 8080 from the local subnet only
sudo nft add rule inet filter input ip saddr 192.168.1.0/24 tcp dport 8080 accept
# Show rules with handles so you can delete one
sudo nft -a list chain inet filter input
sudo nft delete rule inet filter input handle 12
# Save the running ruleset back to the config
sudo nft list ruleset | sudo tee /etc/nftables.conf > /dev/nullAdjust the subnet to match your own network, which you can see with ip -brief address.
Option B: ufw for a simpler workflow
If you would rather not maintain a ruleset file, ufw gets you to a safe default in a handful of commands. Install it and set the policies:
sudo apt update
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoingOpen the services you need before turning it on. If you administer the machine over SSH, this order matters:
sudo ufw allow ssh
sudo ufw allow from 192.168.1.0/24 to any port 8080 proto tcp comment 'lab web server'
sudo ufw enable
sudo ufw status verboseufw enable also registers the service so rules return after a reboot. To remove a rule, list them with numbers and delete by index:
sudo ufw status numbered
sudo ufw delete 2Logging is off by default; sudo ufw logging low writes blocked packets to the journal, which you can follow with journalctl -k -f. If you prefer a window, sudo apt install gufw gives you a graphical panel that edits the same rules.
One thing to be aware of: ufw is built on iptables, which on Debian 13 is the nftables-backed shim. That works, but if you later run nft list ruleset you will see a large set of auto-generated chains. That is expected, and it is also why you should not hand-edit /etc/nftables.conf on a machine that uses ufw. Stop and disable nftables.service if you go the ufw route, or leave ufw uninstalled if you go the nftables route.
nftables vs ufw: which one should you use?
| nftables | ufw | |
|---|---|---|
| Learning curve | Moderate; one config file with its own syntax | Low; short commands |
| Expressiveness | Full: sets, maps, rate limits, NAT, IPv4/IPv6 in one table | Covers common cases; advanced rules go in /etc/ufw/*.rules |
| Transparency | What you wrote is exactly what is loaded | Generates many chains behind the scenes |
| GUI | None in the base system | gufw |
| Good fit for | Servers, labs with several subnets, anyone who wants to understand the rules | Laptops and desktops where “block everything inbound except X” is enough |
For a pentesting laptop that moves between networks, either is fine; the deciding factor is usually whether you want to read a ruleset or type commands. If you later run Parrot’s Cloud edition on a VPS, nftables is the better habit to build.
Things that interact with your firewall on Parrot
- Docker. The Docker daemon inserts its own chains to publish container ports, and those rules can bypass a ufw policy. If you use containers, read the Docker usage notes and bind published ports to
127.0.0.1unless you really mean to expose them. - AnonSurf. The anonymization tool redirects traffic through Tor by rewriting netfilter rules while it is active. Check
nft list rulesetbefore and after toggling it so you know what state you are in, and see the AnonSurf page for the details. - Virtual machines. VirtualBox, VMware and libvirt create bridge interfaces and sometimes their own NAT rules. If a VM suddenly cannot reach the network after you tightened the firewall, allow traffic on that bridge interface (for example
iifname "virbr0" accept) rather than loosening everything. - AppArmor and Firejail. These confine applications rather than filter packets, but they complement a firewall well. The AppArmor and Firejail pages explain how they fit in.
Testing your rules safely
Test only against machines you own or are authorized to assess, such as your own Parrot box or a lab VM. From a second machine or VM on the same network, run a quick scan of the host you just locked down:
nmap -sS -p 1-1024 192.168.1.50Ports you allowed should report open if a service is listening; everything else should show filtered (dropped silently) rather than closed, which confirms the drop policy is in effect. On the firewall host, watch the log entries appear in real time:
sudo journalctl -k -f | grep -E 'nft-drop|UFW BLOCK'Keep the firewall in place when you update the system. Following the safe upgrade process will not remove your rules, but a major upgrade can change package versions of nftables or ufw, so re-run nft list ruleset or ufw status afterwards. The nftables wiki and the Debian nftables page are the authoritative references when you need syntax beyond what is covered here.
FAQ
Does Parrot Linux come with a firewall enabled?
The kernel has netfilter built in, and nftables is normally installed on a Debian 13 base, but whether a ruleset is loaded depends on the edition and your choices. Run sudo nft list ruleset on your own install; an empty result means nothing is filtering.
Can I use nftables and ufw together?
Technically yes, because ufw ends up writing nftables rules through the iptables shim, but you will lose track of which tool owns which rule. Use one and disable the other.
Will a firewall block my own scans and tools?
The rulesets above only filter inbound connections and allow all outbound traffic, so tools such as nmap, curl and Metasploit’s outbound sessions work normally. Reverse shells or listeners you start on the Parrot machine, however, need an explicit inbound allow rule on the port they use.