Advanced ruleset for dynamic environments - Revision history

Jeff.welling: Figured out and documented kernel versions for table creation implicit vs explicit

2018-01-27T00:32:36Z

Figured out and documented kernel versions for table creation implicit vs explicit

← Older revision		Revision as of 00:32, 27 January 2018
Line 20:		Line 20:
	Called from Systemd service file for nftables in ''ExecStart=''		Called from Systemd service file for nftables in ''ExecStart=''

	The table creation statements are kept intentionally separate in this example so that its compatible with both config file formats. With the nftables-output config format, table creation statements cannot be used after the table is already created or an error is thrown, aborting the config reload.		The table creation statements are kept intentionally separate in this example so that its compatible with both config file formats. With the nftables-output config format, table creation statements cannot be used after the table is already created or an error is thrown, aborting the config reload.

			'''Note:''' If you use Debian Stretch or a newer kernel (Linux Kernel >=4.9.0), this isn't necessary - the table creation will be handled implicitly so you can just add a 'flush ruleset' to ''/etc/nftables.conf'', update ''/etc/systemd/system/nftables.service'' so ''ExecStart='' points to ''/etc/nftables.conf'', and delete ''/etc/nftables.start.conf''.

	Example contents of ''/etc/nft.conf.d/nftables.start.conf'':		Example contents of ''/etc/nft.conf.d/nftables.start.conf'':

Jeff.welling: Note Consul's lack of execution guarantee, suggest Ansible in example use case.

2018-01-26T22:42:32Z

Note Consul's lack of execution guarantee, suggest Ansible in example use case.

← Older revision		Revision as of 22:42, 26 January 2018
Line 3:		Line 3:
	Today's modern computing environments require features like Service Discovery and the environments themselves can be quite dynamic and rapidly changing. One of the ways nftables can help is by breaking firewall config into small pieces which can by dynamically generated by the likes of [https://www.consul.io/ Consul] and [https://www.hashicorp.com/blog/introducing-consul-template Consul Template], [https://www.vaultproject.io/ Vault], or config management like [https://www.chef.io/solutions/infrastructure-automation/ Chef] [https://puppet.com/ Puppet] or [https://www.ansible.com/ Ansible].		Today's modern computing environments require features like Service Discovery and the environments themselves can be quite dynamic and rapidly changing. One of the ways nftables can help is by breaking firewall config into small pieces which can by dynamically generated by the likes of [https://www.consul.io/ Consul] and [https://www.hashicorp.com/blog/introducing-consul-template Consul Template], [https://www.vaultproject.io/ Vault], or config management like [https://www.chef.io/solutions/infrastructure-automation/ Chef] [https://puppet.com/ Puppet] or [https://www.ansible.com/ Ansible].

	An example use case would be if you had a number of servers, and you detected traffic on one host that you'd like to block across your entire fleet. You could add the IP to block into Consul, which will propagate it out and then Consul Template on each hosts updates nftables blacklist set definition with the new blacklisted IP and reloads nftables.		An example use case would be if you had a number of servers, and you detected traffic on one host that you'd like to block across your entire fleet. You could add the IP to block into Consul, which will propagate it out and then Consul Template on each hosts updates nftables blacklist set definition with the new blacklisted IP and reloads nftables. Alternatively if you don't trust Consul due to the lack of an execution guarantee, you could put the blocked IP in an Ansible var and deploy it everywhere through your configuration management system.

	By default your Systemd service file likely lives in ''/lib/systemd/system/'', the values suggested on this page are not default so you may wish to change those values. If you do, it's [https://unix.stackexchange.com/questions/206315/what-is-difference-between-usr-lib-and-etc-systemd best practice] to copy the nftables.service file to ''/etc/systemd/system'' where it will override the system-provided version without the need to modify files provided by the package.		By default your Systemd service file likely lives in ''/lib/systemd/system/'', the values suggested on this page are not default so you may wish to change those values. If you do, it's [https://unix.stackexchange.com/questions/206315/what-is-difference-between-usr-lib-and-etc-systemd best practice] to copy the nftables.service file to ''/etc/systemd/system'' where it will override the system-provided version without the need to modify files provided by the package.

Jeff.welling: Added a use case

2018-01-26T22:26:22Z

Added a use case

← Older revision		Revision as of 22:26, 26 January 2018
Line 2:		Line 2:

	Today's modern computing environments require features like Service Discovery and the environments themselves can be quite dynamic and rapidly changing. One of the ways nftables can help is by breaking firewall config into small pieces which can by dynamically generated by the likes of [https://www.consul.io/ Consul] and [https://www.hashicorp.com/blog/introducing-consul-template Consul Template], [https://www.vaultproject.io/ Vault], or config management like [https://www.chef.io/solutions/infrastructure-automation/ Chef] [https://puppet.com/ Puppet] or [https://www.ansible.com/ Ansible].		Today's modern computing environments require features like Service Discovery and the environments themselves can be quite dynamic and rapidly changing. One of the ways nftables can help is by breaking firewall config into small pieces which can by dynamically generated by the likes of [https://www.consul.io/ Consul] and [https://www.hashicorp.com/blog/introducing-consul-template Consul Template], [https://www.vaultproject.io/ Vault], or config management like [https://www.chef.io/solutions/infrastructure-automation/ Chef] [https://puppet.com/ Puppet] or [https://www.ansible.com/ Ansible].

			An example use case would be if you had a number of servers, and you detected traffic on one host that you'd like to block across your entire fleet. You could add the IP to block into Consul, which will propagate it out and then Consul Template on each hosts updates nftables blacklist set definition with the new blacklisted IP and reloads nftables.

	By default your Systemd service file likely lives in ''/lib/systemd/system/'', the values suggested on this page are not default so you may wish to change those values. If you do, it's [https://unix.stackexchange.com/questions/206315/what-is-difference-between-usr-lib-and-etc-systemd best practice] to copy the nftables.service file to ''/etc/systemd/system'' where it will override the system-provided version without the need to modify files provided by the package.		By default your Systemd service file likely lives in ''/lib/systemd/system/'', the values suggested on this page are not default so you may wish to change those values. If you do, it's [https://unix.stackexchange.com/questions/206315/what-is-difference-between-usr-lib-and-etc-systemd best practice] to copy the nftables.service file to ''/etc/systemd/system'' where it will override the system-provided version without the need to modify files provided by the package.

Jeff.welling: Note behavioural change - table creation is implicit now?

2018-01-26T22:21:33Z

Note behavioural change - table creation is implicit now?

← Older revision		Revision as of 22:21, 26 January 2018
Line 7:		Line 7:
	There's nothing wrong with using a different layout, or even having everything in one file. This author prefers to split out rules and sets into individual files so that grouping them together by application or purpose is easier, you can use any configuration structure you wish.		There's nothing wrong with using a different layout, or even having everything in one file. This author prefers to split out rules and sets into individual files so that grouping them together by application or purpose is easier, you can use any configuration structure you wish.

			'''''TODO:''''' Is ''/etc/nftables.start.conf'' really necessary? In a Debian test system on Linux 4.9.0, Debian Stretch, Nftables version v0.7, this file is not necessary - table creation is implicit from the table definition, for both 'inet' and 'ip' table types. This differs from my tests on the system I've lost access to at the moment, this needs to be explored once the host is reset. Note version numbers if the behaviour changed.

Jeff.welling at 20:03, 26 January 2018

2018-01-26T20:03:21Z

← Older revision		Revision as of 20:03, 26 January 2018
Line 4:		Line 4:

	By default your Systemd service file likely lives in ''/lib/systemd/system/'', the values suggested on this page are not default so you may wish to change those values. If you do, it's [https://unix.stackexchange.com/questions/206315/what-is-difference-between-usr-lib-and-etc-systemd best practice] to copy the nftables.service file to ''/etc/systemd/system'' where it will override the system-provided version without the need to modify files provided by the package.		By default your Systemd service file likely lives in ''/lib/systemd/system/'', the values suggested on this page are not default so you may wish to change those values. If you do, it's [https://unix.stackexchange.com/questions/206315/what-is-difference-between-usr-lib-and-etc-systemd best practice] to copy the nftables.service file to ''/etc/systemd/system'' where it will override the system-provided version without the need to modify files provided by the package.

			There's nothing wrong with using a different layout, or even having everything in one file. This author prefers to split out rules and sets into individual files so that grouping them together by application or purpose is easier, you can use any configuration structure you wish.

Jeff.welling at 19:57, 26 January 2018

2018-01-26T19:57:46Z

Show changes

Jeff.welling: Started working on a more advanced config that supports service discovery

2018-01-26T00:17:28Z

Started working on a more advanced config that supports service discovery

New page

'''This page is an unvetted draft'''

Today's modern computing environments require features like Service Discovery and the environments themselves can be quite dynamic and rapidly changing. One of the ways nftables can help is by breaking firewall config into small pieces which can by dynamically generated by the likes of [https://www.consul.io/ Consul] and [https://www.hashicorp.com/blog/introducing-consul-template Consul Template], [https://www.vaultproject.io/ Vault], or config management like [https://www.chef.io/solutions/infrastructure-automation/ Chef] [https://puppet.com/ Puppet] or [https://www.ansible.com/ Ansible].

'''/etc/nftables.start.conf'''
Creates tables
Loads /etc/nftables.conf

'''/etc/nftables.conf'''
Loads table-specific entries like /etc/nft.conf.d/nftables.ip.filter.conf and /etc/nft.conf.d/nftables.ip.nat.conf
Loads Sets main file /etc/nft.conf.d/main.conf

'''/etc/nft.conf.d/main.conf'''
Loads each individual Set, because nftables doesn't support wildcards in ''include'' statements (/etc/nft.conf.d/sets.d/trusted_ips.conf)

'''/etc/nft.conf.d/nftables.ip.filter.conf'''
Configures the 'ip filter' table

'''/etc/nft.conf.d/nftables.ip.nat.conf'''
Configures the 'ip nat' table