Firewalling Basics - Revision history

KN6DWI: Added warning to move public-facing interfaces out of FedoraWorkstation zone

2026-09-01T23:10:47Z

Added warning to move public-facing interfaces out of FedoraWorkstation zone

← Older revision		Revision as of 23:10, 1 September 2026
Line 46:		Line 46:

	It's best to put public-facing interfaces into a <code>default</code> or <code>DROP</code> target zone. <code>ACCEPT</code> will allow unwanted or malicious traffic, and <code>REJECT</code> will spend lots of bandwidth replying to the barrage of traffic from bots scanning the internet. Devices owned by you but publicly accessible from the internet are typically put in a demilitarized zone (DMZ), a network area with only some access to the LAN. This typically involves preventing DMZ devices from initiating connections to LAN devices, but allowing the opposite. <code>firewalld</code> comes with a <code>dmz</code> zone by default, and this is a good place to put the interface that faces your 44Net subnet. (Note that your LAN interface must also be in a default accept zone for it to allow initiating connections to DMZ devices.)		It's best to put public-facing interfaces into a <code>default</code> or <code>DROP</code> target zone. <code>ACCEPT</code> will allow unwanted or malicious traffic, and <code>REJECT</code> will spend lots of bandwidth replying to the barrage of traffic from bots scanning the internet. Devices owned by you but publicly accessible from the internet are typically put in a demilitarized zone (DMZ), a network area with only some access to the LAN. This typically involves preventing DMZ devices from initiating connections to LAN devices, but allowing the opposite. <code>firewalld</code> comes with a <code>dmz</code> zone by default, and this is a good place to put the interface that faces your 44Net subnet. (Note that your LAN interface must also be in a default accept zone for it to allow initiating connections to DMZ devices.)

			'''Warning:''' Fedora comes with the <code>FedoraWorkstation</code> zone as the default zone for all interfaces. It leaves open all ports above 1024. ''This configuration is not suitable for public-facing interfaces.'' Always move interfaces directly exposed to the internet, such as 44Net Connect tunnels, to a more restrictive zone.

	<code>firewalld</code> can be controlled using the <code>firewall-cmd</code> utility, or by editing the config file at <code>/etc/firewalld</code>. Typical policy changes introduced using <code>firewall-cmd</code> are called "runtime" changes, and will not persist after a restart of the service or a reboot. Permanent changes can be made by adding the <code>--permanent</code> flag, or by introducing runtime changes and then invoking <code>firewall-cmd --runtime-to-permanent</code>, which saves all current runtime changes to permanent configuration.		<code>firewalld</code> can be controlled using the <code>firewall-cmd</code> utility, or by editing the config file at <code>/etc/firewalld</code>. Typical policy changes introduced using <code>firewall-cmd</code> are called "runtime" changes, and will not persist after a restart of the service or a reboot. Permanent changes can be made by adding the <code>--permanent</code> flag, or by introducing runtime changes and then invoking <code>firewall-cmd --runtime-to-permanent</code>, which saves all current runtime changes to permanent configuration.

KN6DWI: /* ufw */

2026-08-03T19:10:25Z

ufw

← Older revision		Revision as of 19:10, 3 August 2026
Line 71:		Line 71:
	-- ------ ----		-- ------ ----
	22/tcp ALLOW Anywhere # SSH port</nowiki>		22/tcp ALLOW Anywhere # SSH port</nowiki>

			<code>ufw</code> uses similar targets to <code>firewalld</code>, except it uses <code>deny</code> instead of <code>DROP</code>. To put a 44Net subnet in a {{term:DMZ}}, apply the following rules.
			<nowiki>
			sudo ufw reject in on <subnet interface> to <LAN interface>
			sudo ufw accept in on <LAN interface> to <subnet interface></nowiki>

	By default, Docker writes its own <code>iptables</code> rules and ignores <code>ufw</code> rules. This can cause conflicts and security issues in combination with <code>ufw</code>.<ref>“Uncomplicated Firewall - ArchWiki.” 2024. Archlinux.Org. https://wiki.archlinux.org/title/Uncomplicated_Firewall.</ref>		By default, Docker writes its own <code>iptables</code> rules and ignores <code>ufw</code> rules. This can cause conflicts and security issues in combination with <code>ufw</code>.<ref>“Uncomplicated Firewall - ArchWiki.” 2024. Archlinux.Org. https://wiki.archlinux.org/title/Uncomplicated_Firewall.</ref>

KN6DWI: Recommend putting 44Net devices in a DMZ

2026-08-03T18:22:21Z

Recommend putting 44Net devices in a DMZ

← Older revision		Revision as of 18:22, 3 August 2026
Line 45:		Line 45:
	Check your current zone configuration by running <code>sudo firewalld --list-all-zones</code>.		Check your current zone configuration by running <code>sudo firewalld --list-all-zones</code>.

	It's best to put public-facing interfaces into a <code>default</code> or <code>DROP</code> target zone. <code>ACCEPT</code> will allow unwanted or malicious traffic, and <code>REJECT</code> will spend lots of bandwidth replying to the barrage of traffic from bots scanning the internet.		It's best to put public-facing interfaces into a <code>default</code> or <code>DROP</code> target zone. <code>ACCEPT</code> will allow unwanted or malicious traffic, and <code>REJECT</code> will spend lots of bandwidth replying to the barrage of traffic from bots scanning the internet. Devices owned by you but publicly accessible from the internet are typically put in a demilitarized zone (DMZ), a network area with only some access to the LAN. This typically involves preventing DMZ devices from initiating connections to LAN devices, but allowing the opposite. <code>firewalld</code> comes with a <code>dmz</code> zone by default, and this is a good place to put the interface that faces your 44Net subnet. (Note that your LAN interface must also be in a default accept zone for it to allow initiating connections to DMZ devices.)

	<code>firewalld</code> can be controlled using the <code>firewall-cmd</code> utility, or by editing the config file at <code>/etc/firewalld</code>. Typical policy changes introduced using <code>firewall-cmd</code> are called "runtime" changes, and will not persist after a restart of the service or a reboot. Permanent changes can be made by adding the <code>--permanent</code> flag, or by introducing runtime changes and then invoking <code>firewall-cmd --runtime-to-permanent</code>, which saves all current runtime changes to permanent configuration.		<code>firewalld</code> can be controlled using the <code>firewall-cmd</code> utility, or by editing the config file at <code>/etc/firewalld</code>. Typical policy changes introduced using <code>firewall-cmd</code> are called "runtime" changes, and will not persist after a restart of the service or a reboot. Permanent changes can be made by adding the <code>--permanent</code> flag, or by introducing runtime changes and then invoking <code>firewall-cmd --runtime-to-permanent</code>, which saves all current runtime changes to permanent configuration.

KN6DWI: Separated targets out into bullet points

2026-08-03T18:10:49Z

Separated targets out into bullet points

← Older revision		Revision as of 18:10, 3 August 2026
Line 36:		Line 36:
	== High Level Tools ==		== High Level Tools ==
	=== firewalld ===		=== firewalld ===
	<code>firewalld</code> is an <code>nftables</code>-based CLI firewall management tool. It ships by default on CentOS, Fedora, OpenSUSE, RHEL, SUSE Enterprise, and EndeavourOS, and is packaged for many more distributions. It introduces the idea of a "zone," which is a named set of policies that an interface can be assigned to. Each zone has a target, which is set to <code>default</code>, <code>DROP</code>, <code>~~ACCEPT~~</code>, or <code>~~REJECT~~</code>. These targets determine what action will be taken on packets in the zone that don't match any of the rules, services, or ports. <code>default</code> will accept ICMP and drop everything else, <code>DROP</code> will discard packets without notifying the sender, <code>~~ACCEPT~~</code> will ~~allow~~ the packet ~~through,~~ and <code>~~REJECT~~</code> will ~~discard~~ the packet ~~and notify the sender of its rejection~~. Check your current zone configuration by running <code>sudo firewalld --list-all-zones</code>.		<code>firewalld</code> is an <code>nftables</code>-based CLI firewall management tool. It ships by default on CentOS, Fedora, OpenSUSE, RHEL, SUSE Enterprise, and EndeavourOS, and is packaged for many more distributions. It introduces the idea of a "zone," which is a named set of policies that an interface can be assigned to. Each zone has a target, which is set to <code>default</code>, <code>DROP</code>, <code>REJECT</code>, or <code>ACCEPT</code>. These targets determine what action will be taken on packets in the zone that don't match any of the rules, services, or ports.

			* <code>default</code> will accept ICMP and drop everything else.
			* <code>DROP</code> will discard packets without notifying the sender.
			* <code>REJECT</code> will discard the packet and notify the sender of its rejection.
			* <code>ACCEPT</code> will allow the packet through.

			Check your current zone configuration by running <code>sudo firewalld --list-all-zones</code>.

	It's best to put public-facing interfaces into a <code>default</code> or <code>DROP</code> target zone. <code>ACCEPT</code> will allow unwanted or malicious traffic, and <code>REJECT</code> will spend lots of bandwidth replying to the barrage of traffic from bots scanning the internet.		It's best to put public-facing interfaces into a <code>default</code> or <code>DROP</code> target zone. <code>ACCEPT</code> will allow unwanted or malicious traffic, and <code>REJECT</code> will spend lots of bandwidth replying to the barrage of traffic from bots scanning the internet.

KN6DWI: Recommend that people not allow 44Net devices to initiate connections to their LAN

2026-08-03T17:44:06Z

Recommend that people not allow 44Net devices to initiate connections to their LAN

← Older revision		Revision as of 17:44, 3 August 2026
Line 17:		Line 17:
	When configuring any kind of security policy, best practice is to apply the '''principle of least privilege.''' This means that a person or device is given the minimum level of access to perform their job. This minimizes attack surface (the ways in which a malicious party can attack your network) and minimizes damage if a device or user's credentials are compromised. When it comes to configuring a firewall, that means only opening the ports on which you're actually running services, and only allowing communication between network segments if it's actually necessary.		When configuring any kind of security policy, best practice is to apply the '''principle of least privilege.''' This means that a person or device is given the minimum level of access to perform their job. This minimizes attack surface (the ways in which a malicious party can attack your network) and minimizes damage if a device or user's credentials are compromised. When it comes to configuring a firewall, that means only opening the ports on which you're actually running services, and only allowing communication between network segments if it's actually necessary.

	For example, some people confine Internet of Things (IoT) devices to their own {{term\|VLAN}} due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. Some take it a step further, and block {{term\|WAN}} access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.		For example, some people confine Internet of Things (IoT) devices to their own {{term\|VLAN}} due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. We recommend a similar configuration for your 44Net subnet. Some take it a step further, and block {{term\|WAN}} access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.

	When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should not be used for WAN-facing interfaces, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.		When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should not be used for WAN-facing interfaces, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.

KN6DWI: Wording improvement

2026-08-03T17:42:37Z

Wording improvement

← Older revision		Revision as of 17:42, 3 August 2026
Line 19:		Line 19:
	For example, some people confine Internet of Things (IoT) devices to their own {{term\|VLAN}} due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. Some take it a step further, and block {{term\|WAN}} access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.		For example, some people confine Internet of Things (IoT) devices to their own {{term\|VLAN}} due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. Some take it a step further, and block {{term\|WAN}} access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.

	When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should ~~only~~ be used for ~~relatively trusted network segments~~, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.		When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should not be used for WAN-facing interfaces, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.

	== Low Level Tools ==		== Low Level Tools ==

Airgapped: /* Configuration Recommendations */

2026-07-31T19:01:31Z

Configuration Recommendations

← Older revision		Revision as of 19:01, 31 July 2026
Line 17:		Line 17:
	When configuring any kind of security policy, best practice is to apply the '''principle of least privilege.''' This means that a person or device is given the minimum level of access to perform their job. This minimizes attack surface (the ways in which a malicious party can attack your network) and minimizes damage if a device or user's credentials are compromised. When it comes to configuring a firewall, that means only opening the ports on which you're actually running services, and only allowing communication between network segments if it's actually necessary.		When configuring any kind of security policy, best practice is to apply the '''principle of least privilege.''' This means that a person or device is given the minimum level of access to perform their job. This minimizes attack surface (the ways in which a malicious party can attack your network) and minimizes damage if a device or user's credentials are compromised. When it comes to configuring a firewall, that means only opening the ports on which you're actually running services, and only allowing communication between network segments if it's actually necessary.

	For example, some people confine Internet of Things (IoT) devices to their own {{term\|VLAN}}due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. Some take it a step further, and block {{term\|WAN}}access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.		For example, some people confine Internet of Things (IoT) devices to their own {{term\|VLAN}} due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. Some take it a step further, and block {{term\|WAN}} access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.

	When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should only be used for relatively trusted network segments, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.		When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should only be used for relatively trusted network segments, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.

Airgapped: /* Configuration Recommendations */

2026-07-31T18:52:31Z

Configuration Recommendations

← Older revision		Revision as of 18:52, 31 July 2026
Line 17:		Line 17:
	When configuring any kind of security policy, best practice is to apply the '''principle of least privilege.''' This means that a person or device is given the minimum level of access to perform their job. This minimizes attack surface (the ways in which a malicious party can attack your network) and minimizes damage if a device or user's credentials are compromised. When it comes to configuring a firewall, that means only opening the ports on which you're actually running services, and only allowing communication between network segments if it's actually necessary.		When configuring any kind of security policy, best practice is to apply the '''principle of least privilege.''' This means that a person or device is given the minimum level of access to perform their job. This minimizes attack surface (the ways in which a malicious party can attack your network) and minimizes damage if a device or user's credentials are compromised. When it comes to configuring a firewall, that means only opening the ports on which you're actually running services, and only allowing communication between network segments if it's actually necessary.

	For example, some people confine Internet of Things (IoT) devices to their own {{term\|VLAN}}due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. Some take it a step further, and block {{term\|WAN}} access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.		For example, some people confine Internet of Things (IoT) devices to their own {{term\|VLAN}}due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. Some take it a step further, and block {{term\|WAN}}access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.

	When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should only be used for relatively trusted network segments, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.		When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should only be used for relatively trusted network segments, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.

Airgapped: /* Configuration Recommendations */

2026-07-31T18:52:16Z

Configuration Recommendations

← Older revision		Revision as of 18:52, 31 July 2026
Line 17:		Line 17:
	When configuring any kind of security policy, best practice is to apply the '''principle of least privilege.''' This means that a person or device is given the minimum level of access to perform their job. This minimizes attack surface (the ways in which a malicious party can attack your network) and minimizes damage if a device or user's credentials are compromised. When it comes to configuring a firewall, that means only opening the ports on which you're actually running services, and only allowing communication between network segments if it's actually necessary.		When configuring any kind of security policy, best practice is to apply the '''principle of least privilege.''' This means that a person or device is given the minimum level of access to perform their job. This minimizes attack surface (the ways in which a malicious party can attack your network) and minimizes damage if a device or user's credentials are compromised. When it comes to configuring a firewall, that means only opening the ports on which you're actually running services, and only allowing communication between network segments if it's actually necessary.

	For example, some people confine Internet of Things (IoT) devices to their own {{term\|VLAN}}		For example, some people confine Internet of Things (IoT) devices to their own {{term\|VLAN}}due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. Some take it a step further, and block {{term\|WAN}} access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.
	due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. Some take it a step further, and block {{term\|WAN}} access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.

	When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should only be used for relatively trusted network segments, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.		When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should only be used for relatively trusted network segments, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.

Airgapped: /* Configuration Recommendations */

2026-07-31T18:52:04Z

Configuration Recommendations

← Older revision		Revision as of 18:52, 31 July 2026
Line 18:		Line 18:

	For example, some people confine Internet of Things (IoT) devices to their own {{term\|VLAN}}		For example, some people confine Internet of Things (IoT) devices to their own {{term\|VLAN}}
	due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. Some take it a step further, and block {{term\|WAN}}access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.		due to their often poor security. In such a configuration, you might allow devices from the regular LAN to initiate connections to the IoT devices, but not the other way around, to prevent a compromised IoT device from attacking the rest of your network. Some take it a step further, and block {{term\|WAN}} access from the IoT VLAN to prevent devices from sending telemetry to their manufacturer.

	When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should only be used for relatively trusted network segments, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.		When restricting access between devices on your internal network, it can be helpful to use a policy that explicitly rejects disallowed packets rather than silently dropping them. This feedback can be helpful when troubleshooting, as it immediately lets you know that packets are being blocked by firewall policy rather than something like a port mismatch or a hostname/IP typo. Reject policies should only be used for relatively trusted network segments, otherwise you may spend lots of compute power sending packet rejections to automated scanners and other malicious actors on the wider internet.