Iceditch IPtables language - Revision history

Saruman!: updated targets and custom chains

2008-08-10T14:07:34Z

updated targets and custom chains

← Older revision		Revision as of 16:07, 10 August 2008
Line 12:		Line 12:
	* OUTPUT		* OUTPUT
	* POSTROUTING		* POSTROUTING
	Iceditch ~~will (currently) not understand any other chain~~.		Iceditch understands these built-in chains, and can also help you create custom chains.
	There is also a number of default tables:		There is also a number of default tables:
	* conntrack		* conntrack
Line 18:		Line 18:
	* nat		* nat
	* filter		* filter
	The "conntrack" table is not user manipulable, so Iceditch won't (cannot) allow you to it.		The "conntrack" table is not user manipulable, so Iceditch won't (cannot) allow you to do anything in/with it.

	Now please have a peek at the following [[nfk-traversal-picture \| magnificent picture]]. You can see that there are only 11 combinations of default chains and tables that can accept IPtables rules. Fear not: '''Iceditch will check every rule for valid combination of table and chain''', and yield an error message for any invalid combination. The valid combinations thus are:		Now please have a peek at the following [[nfk-traversal-picture \| magnificent picture]]. You can see that there are only 11 combinations of default chains and tables that can accept IPtables rules. Fear not: '''Iceditch will check every rule for valid combination of table and chain''', and yield an error message for any invalid combination. The valid combinations thus are:
	{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"		{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"
Line 56:		Line 57:
	\| V		\| V
	\|		\|
			\|-
			\| style="background:lightgrey" \| '''(custom)'''
			\|
			\| V
			\| V
			\| V
	\|-		\|-
	\|}		\|}

			As you can see from the last line, you can create custom chains in the three tables ''filter'', ''mangle'' and ''nat''. After creating a custom chain (e.g. "FTPTRAFFIC" in table "filter") you can create rules in it by setting the context to your custom chain:
			context FTPTRAFFIC filter

	The way to tell Iceditch which table and chain to use, is by grouping all commands for a certain combination of table and chain in one stanza of the configuration file: this is called the ''context'' of the rules. A context is specified in the configuration file with the following header:		The way to tell Iceditch which table and chain to use, is by grouping all commands for a certain combination of table and chain in one stanza of the configuration file: this is called the ''context'' of the rules. A context is specified in the configuration file with the following header:
Line 68:		Line 78:

	===The target specification===		===The target specification===
	(Almost) every IPtables rule has a target. Iceditch takes keywords that signify the standard targets, and lets every line begin with this keyword. Thus, the keyword ''accept'' at the beginning of a line signifies that you're talking about an IPtables command that normally would end with ''-j ACCEPT''. The keywords Iceditch currently "understands" are:		(Almost) every IPtables rule has a target. Iceditch takes keywords that signify the standard IPtables targets, and lets every line begin with this keyword. Thus, the keyword ''accept'' at the beginning of a line signifies that you're talking about an IPtables command that normally would end with ''--jump ACCEPT''. The keywords Iceditch currently "understands" are:
	* accept		* accept
			* classify
			* dnat
	* drop		* drop
			* ipv4optsstrip
			* log
			* mark
			* masquerade
	* reject		* reject
	* ~~redirect~~		* return
	* ~~mark~~		* route
	* ~~classify~~		* same
	* recent
	* dnat
	* snat		* snat
	* masquerade
	* nojump
	The last one is a bit odd: it signifies an IPtables line that can match a packet, yet won't jump anywhere; thus, Iceditch actually doesn't "do" anything with the packet. This would be the case for a line that you'd insert in order to count certain packets, like
	~~iptables -A INPUT -t filter -p icmp -s 10.0.0.1~~
	This line would match any ICMP-packet sent to your machine from IP address 10.0.0.1, but your firewall would not "do" anything with the packet. Thus it would be up to the following lines (or eventually the policy of the table) to actually "do" something with the packet.
	~~With the use of CONTEXT, the example line would look like this:~~
	~~<pre>context "INPUT" "filter"~~
	~~nojump -p icmp -s 10.0.0.1</pre>~~

	===The rule syntax===		===The rule syntax===
Line 92:		Line 98:
	What we've done is create a page called the [[Iceditch Command Reference]], where for every target all options are described. However, this reference presupposes intimate knowledge of IPtables. Currently this wiki does not offer a comprehensive course in IPtables; to obtain this knowledge one might start off at sites like [http://iptables-tutorial.frozentux.net/chunkyhtml/index.html this] and [http://security.maruhn.com/ this one].		What we've done is create a page called the [[Iceditch Command Reference]], where for every target all options are described. However, this reference presupposes intimate knowledge of IPtables. Currently this wiki does not offer a comprehensive course in IPtables; to obtain this knowledge one might start off at sites like [http://iptables-tutorial.frozentux.net/chunkyhtml/index.html this] and [http://security.maruhn.com/ this one].

	===The functionality===		==The functionality==
	Iceditch helps you create an IPtables based firewall. But ''what'' exactly can it do to help you? You can find out by reading the page on [[Iceditch functionality]], where we list both current functionality, as well as future features.		Iceditch helps you create an IPtables based firewall. But ''what'' exactly can it do to help you? You can find out by reading the page on [[Iceditch functionality]], where we list both current functionality, as well as future features.

	===The program structure===		==The program structure==
	Iceditch consists of a number of files, each of which is located in a logical place - at least we think so. For clarity, we've created a comprehensive listing of all the files that comprise the Iceditch package, along with their location and function. It can be found on the [[Iceditch file structure]] page.		Iceditch consists of a number of files, each of which is located in a logical place - at least we think so. For clarity, we've created a comprehensive listing of all the files that comprise the Iceditch package, along with their location and function. It can be found on the [[Iceditch file structure]] page.

Saruman!: added functionality and structure sections/links

2008-06-30T19:33:59Z

added functionality and structure sections/links

← Older revision		Revision as of 21:33, 30 June 2008
Line 91:		Line 91:

	What we've done is create a page called the [[Iceditch Command Reference]], where for every target all options are described. However, this reference presupposes intimate knowledge of IPtables. Currently this wiki does not offer a comprehensive course in IPtables; to obtain this knowledge one might start off at sites like [http://iptables-tutorial.frozentux.net/chunkyhtml/index.html this] and [http://security.maruhn.com/ this one].		What we've done is create a page called the [[Iceditch Command Reference]], where for every target all options are described. However, this reference presupposes intimate knowledge of IPtables. Currently this wiki does not offer a comprehensive course in IPtables; to obtain this knowledge one might start off at sites like [http://iptables-tutorial.frozentux.net/chunkyhtml/index.html this] and [http://security.maruhn.com/ this one].

			===The functionality===
			Iceditch helps you create an IPtables based firewall. But ''what'' exactly can it do to help you? You can find out by reading the page on [[Iceditch functionality]], where we list both current functionality, as well as future features.

			===The program structure===
			Iceditch consists of a number of files, each of which is located in a logical place - at least we think so. For clarity, we've created a comprehensive listing of all the files that comprise the Iceditch package, along with their location and function. It can be found on the [[Iceditch file structure]] page.

Saruman!: /* The rule syntax */ fixed link error

2008-06-29T10:25:58Z

The rule syntax: fixed link error

← Older revision		Revision as of 12:25, 29 June 2008
Line 90:		Line 90:
	For every IPtables rule you want to specify in Iceditch, the syntax is based on the underlying IPtables rule. However, Iceditch rules are structured differently: the context is specified at the beginning of the stanza, the target forms the opening keyword, and there are several optional addition to the target. Therefor, forming a firewall rule in Iceditch requires you to follow both Iceditch syntax rules and IPtables syntax rules. Don't worry, it's actually quite simple.		For every IPtables rule you want to specify in Iceditch, the syntax is based on the underlying IPtables rule. However, Iceditch rules are structured differently: the context is specified at the beginning of the stanza, the target forms the opening keyword, and there are several optional addition to the target. Therefor, forming a firewall rule in Iceditch requires you to follow both Iceditch syntax rules and IPtables syntax rules. Don't worry, it's actually quite simple.

	What we've done is create a page called the [Iceditch Command Reference], where for every target all options are described. However, this reference presupposes intimate knowledge of IPtables. Currently this wiki does not offer a comprehensive course in IPtables; to obtain this knowledge one might start off at sites like [http://iptables-tutorial.frozentux.net/chunkyhtml/index.html this] and [http://security.maruhn.com/ this one].		What we've done is create a page called the [[Iceditch Command Reference]], where for every target all options are described. However, this reference presupposes intimate knowledge of IPtables. Currently this wiki does not offer a comprehensive course in IPtables; to obtain this knowledge one might start off at sites like [http://iptables-tutorial.frozentux.net/chunkyhtml/index.html this] and [http://security.maruhn.com/ this one].

Saruman!: added rule syntax section

2008-06-29T10:25:31Z

added rule syntax section

← Older revision		Revision as of 12:25, 29 June 2008
Line 14:		Line 14:
	Iceditch will (currently) not understand any other chain.		Iceditch will (currently) not understand any other chain.
	There is also a number of default tables:		There is also a number of default tables:
			* conntrack
	* mangle		* mangle
	* nat		* nat
	* filter		* filter
	~~There is also a~~ "conntrack" table~~, but it's~~ not user manipulable, so Iceditch won't ~~recognise~~ it		The "conntrack" table is not user manipulable, so Iceditch won't (cannot) allow you to it.
	Now please have a peek at the following [[nfk-traversal-picture \| magnificent picture]]. You can see that ~~tehre~~ are only 11 combinations of default chains and tables that can accept IPtables rules. Fear not: '''Iceditch will check every rule for valid combination of table and chain''', and yield an error message for any invalid combination. The valid combinations thus are:		Now please have a peek at the following [[nfk-traversal-picture \| magnificent picture]]. You can see that there are only 11 combinations of default chains and tables that can accept IPtables rules. Fear not: '''Iceditch will check every rule for valid combination of table and chain''', and yield an error message for any invalid combination. The valid combinations thus are:
	{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"		{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"
	\|		\|
Line 26:		Line 27:
	!style="background:#ffdead;"\|filter		!style="background:#ffdead;"\|filter
	\|-		\|-
	\| style="background:lightgrey" \| PREROUTING		\| style="background:lightgrey" \| '''PREROUTING'''
	\| X		\| X
	\| V		\| V
	\| V		\| V
	\| X		\|
	\|-		\|-
	\| style="background:lightgrey" \| FORWARD		\| style="background:lightgrey" \| '''FORWARD'''
	\| X		\|
	\| V		\| V
	\| X		\|
	\| V		\| V
	\|-		\|-
	\| style="background:lightgrey" \| INPUT		\| style="background:lightgrey" \| '''INPUT'''
	\| X		\|
	\| V		\| V
			\|
	\| V		\| V
	~~\| X~~
	\|-		\|-
	\| style="background:lightgrey" \| OUTPUT		\| style="background:lightgrey" \| '''OUTPUT'''
	\| X		\| X
	\| V		\| V
Line 50:		Line 51:
	\| V		\| V
	\|-		\|-
	\| style="background:lightgrey" \| POSTROUTING		\| style="background:lightgrey" \| '''POSTROUTING'''
	\| X		\|
	\| V		\| V
	\| V		\| V
	\| X		\|
	\|-		\|-
	\|}		\|}
Line 64:		Line 65:
	Every line that follows is assumed to belong to this particular context, so that in these lines the target chain and table do not need to appear.		Every line that follows is assumed to belong to this particular context, so that in these lines the target chain and table do not need to appear.

	Currently, every context is allowed to appear ~~only once~~ in the configuration file. This ~~might seem restrictive (and it actually is)~~, ~~but it forces you to group all actions that take place~~ in ~~a table~~, so that ~~you actually make sure all actions appear in~~ the ~~right order. Nevertheless, future versions of Iceditch might allow multiple~~ stanzas ~~per unique~~ context.		Currently, every context is allowed to appear multiple times in the configuration file. This means Iceditch allows multiple stanzas per unique context. However, they will be processed in the order in which they appear in the configuration file, so one must be careful that the stanzas are ordered correctly; we'd advise to use each context only once, for maintainability over legibility.

	===The target specification===		===The target specification===
Line 85:		Line 86:
	<pre>context "INPUT" "filter"		<pre>context "INPUT" "filter"
	nojump -p icmp -s 10.0.0.1</pre>		nojump -p icmp -s 10.0.0.1</pre>

			===The rule syntax===
			For every IPtables rule you want to specify in Iceditch, the syntax is based on the underlying IPtables rule. However, Iceditch rules are structured differently: the context is specified at the beginning of the stanza, the target forms the opening keyword, and there are several optional addition to the target. Therefor, forming a firewall rule in Iceditch requires you to follow both Iceditch syntax rules and IPtables syntax rules. Don't worry, it's actually quite simple.

			What we've done is create a page called the [Iceditch Command Reference], where for every target all options are described. However, this reference presupposes intimate knowledge of IPtables. Currently this wiki does not offer a comprehensive course in IPtables; to obtain this knowledge one might start off at sites like [http://iptables-tutorial.frozentux.net/chunkyhtml/index.html this] and [http://security.maruhn.com/ this one].

Saruman!: put in the chain/table overview table

2008-06-28T21:39:25Z

put in the chain/table overview table

@@ Line 18: / Line 18: @@
 * filter
 There is also a "conntrack" table, but it's not user manipulable, so Iceditch won't recognise it
-Now please have a peek at the following [[nfk-traversal-picture | magnificent picture]]. You can see that tehre are only 11 combinations of default chains and tables that can accept IPtables rules. Fear not: '''Iceditch will check every rule for valid combination of table and chain''', and yield an error message for any invalid combination.
+Now please have a peek at the following [[nfk-traversal-picture | magnificent picture]]. You can see that tehre are only 11 combinations of default chains and tables that can accept IPtables rules. Fear not: '''Iceditch will check every rule for valid combination of table and chain''', and yield an error message for any invalid combination. The valid combinations thus are:
-The way to tell Iceditch which table and chain to use, is by grouping all commands for a certain combination of table and chain in one stanza of the configuration file: this is called the ''context'' of the rules. A context is specified in the configuration file with the following header
+The way to tell Iceditch which table and chain to use, is by grouping all commands for a certain combination of table and chain in one stanza of the configuration file: this is called the ''context'' of the rules. A context is specified in the configuration file with the following header:
-  context <chain> <table>
+<pre>
 Every line that follows is assumed to belong to this particular context, so that in these lines the target chain and table do not need to appear.

Saruman!: cleaning up

2008-06-27T20:46:48Z

cleaning up

← Older revision		Revision as of 22:46, 27 June 2008
Line 18:		Line 18:
	* filter		* filter
	There is also a "conntrack" table, but it's not user manipulable, so Iceditch won't recognise it		There is also a "conntrack" table, but it's not user manipulable, so Iceditch won't recognise it
	Now please have a peek at the following [[nfk-traversal-picture \| magnificent picture]]. You can see that tehre are only 11 combinations of default chains and tables that can accept IPtables rules. Fear not: Iceditch will check every rule for valid combination of table and chain, and yield an error message for any invalid combination.		Now please have a peek at the following [[nfk-traversal-picture \| magnificent picture]]. You can see that tehre are only 11 combinations of default chains and tables that can accept IPtables rules. Fear not: '''Iceditch will check every rule for valid combination of table and chain''', and yield an error message for any invalid combination.

	The way to tell Iceditch which table and chain to use, is by grouping all commands for a certain combination of table and chain in one stanza of the configuration file: this is called the ''context'' of the rules. A context is specified in the configuration file with the following header		The way to tell Iceditch which table and chain to use, is by grouping all commands for a certain combination of table and chain in one stanza of the configuration file: this is called the ''context'' of the rules. A context is specified in the configuration file with the following header
Line 24:		Line 24:
	Every line that follows is assumed to belong to this particular context, so that in these lines the target chain and table do not need to appear.		Every line that follows is assumed to belong to this particular context, so that in these lines the target chain and table do not need to appear.

	Currently, every context is allowed only once in the configuration file		Currently, every context is allowed to appear only once in the configuration file. This might seem restrictive (and it actually is), but it forces you to group all actions that take place in a table, so that you actually make sure all actions appear in the right order. Nevertheless, future versions of Iceditch might allow multiple stanzas per unique context.

	===The target specification==		===The target specification===
	(Almost) every IPtables rule has a target. Iceditch takes keywords that signify the standard targets, and lets every line begin with this keyword. Thus, the keyword ''accept'' at the beginning of a line signifies that you're talking about an IPtables command that normally would end with ''-j ACCEPT''. The keywords Iceditch currently "understands" are:		(Almost) every IPtables rule has a target. Iceditch takes keywords that signify the standard targets, and lets every line begin with this keyword. Thus, the keyword ''accept'' at the beginning of a line signifies that you're talking about an IPtables command that normally would end with ''-j ACCEPT''. The keywords Iceditch currently "understands" are:
	* accept		* accept
Line 39:		Line 39:
	* masquerade		* masquerade
	* nojump		* nojump
	The last one is a bit odd: it signifies an IPtables line that can match a packet, yet won't jump anywhere. This would be the case for a line that you'd insert in order to count certain packets, like		The last one is a bit odd: it signifies an IPtables line that can match a packet, yet won't jump anywhere; thus, Iceditch actually doesn't "do" anything with the packet. This would be the case for a line that you'd insert in order to count certain packets, like
	iptables -A INPUT -t filter -p icmp -s 10.0.0.1		iptables -A INPUT -t filter -p icmp -s 10.0.0.1
	This line would match any ICMP-packet sent to your machine from IP address 10.0.0.1, but your firewall would not "do" anything with the packet. Thus it would be up to the following lines (or eventually the policy of the table) to actually "do" something with the packet.		This line would match any ICMP-packet sent to your machine from IP address 10.0.0.1, but your firewall would not "do" anything with the packet. Thus it would be up to the following lines (or eventually the policy of the table) to actually "do" something with the packet.
	With the use of CONTEXT, the example line would look like this:		With the use of CONTEXT, the example line would look like this:
	<pre>		<pre>context "INPUT" "filter"
	context "INPUT" "filter"		nojump -p icmp -s 10.0.0.1</pre>
	nojump -p icmp -s 10.0.0.1
	</pre>

Saruman!: /* =The target specification */ rectified example box

2008-06-27T20:42:01Z

=The target specification: rectified example box

← Older revision		Revision as of 22:42, 27 June 2008
Line 43:		Line 43:
	This line would match any ICMP-packet sent to your machine from IP address 10.0.0.1, but your firewall would not "do" anything with the packet. Thus it would be up to the following lines (or eventually the policy of the table) to actually "do" something with the packet.		This line would match any ICMP-packet sent to your machine from IP address 10.0.0.1, but your firewall would not "do" anything with the packet. Thus it would be up to the following lines (or eventually the policy of the table) to actually "do" something with the packet.
	With the use of CONTEXT, the example line would look like this:		With the use of CONTEXT, the example line would look like this:
			<pre>
	context "INPUT" "filter"		context "INPUT" "filter"
	nojump -p icmp -s 10.0.0.1		nojump -p icmp -s 10.0.0.1
			</pre>

Saruman!: added target spec

2008-06-27T20:41:14Z

added target spec

@@ Line 1: / Line 1: @@
 ==The Iceditch control language==
-If you know and understand [http://iptables-tutorial.frozentux.net/iptables-tutorial.html IPtables commands], then the syntax of the Iceditch control language seems very simple to you. When you realise that it's only goal is to simplify standard IPtables commands __without__ taking away their incredible power or flexibility, you'll also realise that this is actually inevitable. But let's not linger here: dip in!
+If you know and understand [http://iptables-tutorial.frozentux.net/iptables-tutorial.html IPtables commands], then the syntax of the Iceditch control language seems very simple to you. When you realise that it's only goal is to simplify standard IPtables commands ''without'' taking away their incredible power or flexibility, you'll also realise that this is actually inevitable. But let's not linger here: dip in!
 === The ''Context'' header===
 Just about every IPtables command that ''creates'' a firewall rule, acts on some firewall table, and some firewall chain. These are found in the IPtables invocation, and are specified by options -A (add to chain) and -t (use table). Thus, the rule
   iptables -A INPUT -t filter -d 10.0.0.1 -j DROP
-works in chain ''INPUT'' and table ''filter''.
+works in chain ''INPUT'' and table ''filter''. There is a number of default chains:

Saruman!: Started explaining Context

2008-06-27T19:25:56Z

Started explaining Context

New page

==The Iceditch control language==

If you know and understand [http://iptables-tutorial.frozentux.net/iptables-tutorial.html IPtables commands], then the syntax of the Iceditch control language seems very simple to you. When you realise that it's only goal is to simplify standard IPtables commands __without__ taking away their incredible power or flexibility, you'll also realise that this is actually inevitable. But let's not linger here: dip in!

=== The ''Context'' header===
Just about every IPtables command that ''creates'' a firewall rule, acts on some firewall table, and some firewall chain. These are found in the IPtables invocation, and are specified by options -A (add to chain) and -t (use table). Thus, the rule
iptables -A INPUT -t filter -d 10.0.0.1 -j DROP
works in chain ''INPUT'' and table ''filter''.