Admin: Text replacement - "Category:Wiki" to "Category:Wiki '''''[https://it-arts.net/index.php/Category:Wiki Return to Wiki Index]''''' "

2026-01-17T08:52:34Z

Text replacement - "Category:Wiki" to "Category:Wiki '''''[https://it-arts.net/index.php/Category:Wiki Return to Wiki Index]''''' "

← Older revision		Revision as of 08:52, 17 January 2026
Line 1:		Line 1:
	[[Category:Wiki]]		[[Category:Wiki]]

			'''''[https://it-arts.net/index.php/Category:Wiki Return to Wiki Index]'''''


	== Organizing Configuration Files ==		== Organizing Configuration Files ==

Admin: Created page with "Category:Wiki == Organizing Configuration Files == A good practice is to organize `nft` configuration files into logical sections to ensure clarity and maintainability. Avoid putting all rules into a single file. Instead, create different files for different contexts (e.g., input, output, forward, etc.) and then include them in a master configuration file. Example: # Main configuration file table inet filter { include "/etc/nftables/ipv4.rules" i..."

2025-12-14T08:07:40Z

Created page with "Category:Wiki == Organizing Configuration Files == A good practice is to organize `nft` configuration files into logical sections to ensure clarity and maintainability. Avoid putting all rules into a single file. Instead, create different files for different contexts (e.g., input, output, forward, etc.) and then include them in a master configuration file. Example: <nowiki> # Main configuration file table inet filter { include "/etc/nftables/ipv4.rules" i..."

New page

[[Category:Wiki]]

== Organizing Configuration Files ==

A good practice is to organize `nft` configuration files into logical sections to ensure clarity and maintainability. Avoid putting all rules into a single file. Instead, create different files for different contexts (e.g., input, output, forward, etc.) and then include them in a master configuration file.

Example:
<nowiki>
# Main configuration file
table inet filter {
include "/etc/nftables/ipv4.rules"
include "/etc/nftables/ipv6.rules"
}</nowiki>

This approach allows easy updates and segregation of IPv4 and IPv6 rules.

== Use of Tables, Chains, and Rules ==

When setting up firewall rules, tables, chains, and rules should be logically named to clarify their purpose. Use meaningful names that represent the function of the table or chain, such as `filter`, `nat`, `mangle`, and `security`.

Example:
<nowiki>
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
iifname lo accept
ip protocol icmp accept
}
chain output {
type filter hook output priority 0; policy accept;
}
}</nowiki>

In the example above, `input` and `output` chains are set up under the `filter` table, and rules are defined with appropriate conditions and actions.

== Using State Matching for Connections ==

One of the key features in firewall rule configuration is stateful inspection. Ensure that connection tracking is enabled by using the `ct state` match, which can help optimize performance and ensure that return traffic for established connections is properly handled.

Example:
<nowiki>
chain input {
ct state established,related accept
ip protocol tcp dport 22 accept
ip protocol icmp accept
drop
}</nowiki>

This rule allows established or related connections to be accepted without re-checking the connection state for every packet.

== Limiting Rule Scope for Performance ==

A crucial best practice is to limit the scope of rules to the minimum necessary. Avoid overly broad rules that could slow down the system. For example, instead of allowing all traffic on a network interface, define more specific matches for each protocol or port.

Example:
<nowiki>
chain input {
ip protocol tcp dport 80 accept
ip protocol tcp dport 443 accept
drop
}</nowiki>

By narrowing the scope, the system will process fewer rules, improving performance.

== Logging with Care ==

While logging can be useful for debugging, avoid excessive logging as it can degrade performance and fill up system logs. Only log critical or suspicious traffic and ensure logging is done with specific criteria.

Example:
<nowiki>
chain input {
ip daddr 192.168.1.10 log prefix "Suspicious IP: "
drop
}</nowiki>

Logging suspicious IP addresses can help identify unauthorized access attempts without overwhelming the system with unnecessary log entries.

== Using Sets for Efficient Matching ==

Sets are a powerful feature of `nft` for managing large numbers of items, such as IP addresses or ports. Use sets when you need to match against many values, as they provide better performance than individual rules.

Example:
<nowiki>
set blocked_ips {
type ipv4_addr
elements = { 192.168.1.100, 192.168.1.101 }
}

chain input {
ip saddr @blocked_ips drop
}</nowiki>

In this case, the set `blocked_ips` contains a list of blocked IP addresses. This approach is more efficient than writing individual drop rules for each address.

== Regular Backups of Configuration ==

Always back up your `nft` rules before making changes. You can dump the current rules to a file for safekeeping. This is especially important in production environments.

Example:
<nowiki>
nft list ruleset > /etc/nftables/rules.backup</nowiki>

Regular backups help prevent accidental rule loss and enable easy restoration if issues arise.

== Enable Persistent Configuration ==

Ensure that the firewall configuration persists across system reboots. Most Linux distributions provide a mechanism to automatically apply `nft` rules at boot time. For example, on Debian-based systems, you can save your configuration and ensure it is loaded at boot using the following:

Example:
<nowiki>
nft list ruleset > /etc/nftables.conf</nowiki>

Then enable `nftables` to load this file on boot:
<nowiki>
systemctl enable nftables
systemctl start nftables</nowiki>

This ensures that your firewall rules are automatically applied each time the system starts.

== Test Changes in a Staging Environment ==

Before applying firewall changes to production systems, always test them in a controlled environment. Misconfigurations can lead to loss of connectivity or downtime, so it is essential to test all changes thoroughly before implementing them live.

== IPv6 Best Practices ==

When configuring `nft` for IPv6, be sure to include specific rules for handling IPv6 traffic. By default, IPv6 might not be covered by your IPv4 rules.

Example:
<nowiki>
table inet filter {
chain input {
ip6 protocol icmpv6 accept
ip6 saddr fe80::/10 accept
drop
}
}</nowiki>

This configuration ensures that only essential IPv6 traffic (such as ICMPv6) is allowed, and other traffic is dropped.

== Troubleshooting Tips ==

In case of connectivity issues, use the `nft` command to diagnose and troubleshoot:

* List the active ruleset to verify the current firewall configuration:
<nowiki>
nft list ruleset</nowiki>

* Check if a specific rule is matched:
<nowiki>
nft monitor</nowiki>

This will display real-time packet flow and help identify where packets are being dropped or accepted.

NFT - Guide - Revision history

Admin: Text replacement - "Category:Wiki" to "Category:Wiki '''''[https://it-arts.net/index.php/Category:Wiki Return to Wiki Index]''''' "