Iceditch IPtables language: Difference between revisions
m (→=The target specification: rectified example box) |
m (cleaning up) |
||
| 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" | ||
nojump -p icmp -s 10.0.0.1</pre> | |||
</pre> | |||
Revision as of 22:46, 27 June 2008
The Iceditch control language
If you know and understand 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. There is a number of default chains:
- PREROUTING
- FORWARD
- INPUT
- OUTPUT
- POSTROUTING
Iceditch will (currently) not understand any other chain. There is also a number of default tables:
- mangle
- nat
- 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 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
context <chain>
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.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:
- accept
- drop
- reject
- redirect
- mark
- classify
- recent
- dnat
- 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:
context "INPUT" "filter" nojump -p icmp -s 10.0.0.1