Iceditch Command Reference

Parameter: log

target log [msg <message>] <qualifiers>
After most keywords, a "log" parameter can be added (see below). If the "log" parameter is followed by "msg", then the parameter following "msg" is read and used as log-prefix. The parameter is not allowed to have whitespace, and the maximum length of the log-prefix is determined by your version of netfilter/IPtables (usually some 31 characters). Thus a packet matching the rule will be logged with the default setting of the "log" target.

If the "log" parameter is not followed by "msg", then the packet will be logged with the default log message for that particular target keyword, and all the other default setting of the "log" target. Thus, should you want to log a packet with more control over the logging parameters, then you need an extra line, beginning with the target keyword "log", instead of just following the target keyword with parameter log. For more information, see the target keyword "log" below.

Target keyword: accept

accept [log [msg <message>]] <qualifiers>
If a network packet matches the qualifiers, then it will be accepted (passed) through the table/chain defined in the context where you put the accept rule. Example:

context "INPUT" "filter"
accept –p tcp --dport 22

Iceditch works this out to

 iptables –t filter –A INPUT –p tcp –-dport 22 –-jump ACCEPT

Should you want to log the packet, you’d use

 context "INPUT" "filter"
 accept log –p tcp --dport 22

Iceditch works this out to

 iptables –t filter –A INPUT –p tcp –-dport 22 \
   –-jump LOG --log-prefix INPUT_accept 
 iptables –t filter –A INPUT –p tcp –-dport 22 –-jump ACCEPT

Note: because of how IPtables handles the ACCEPT target, you can only use it in contexts where the table is “filter”.

Target keyword: classify

classify <classval> [log [msg <message>]] <qualifiers>
If a packet travelling through the mangle table in the POSTROUTING chain matches the qualifiers, then it will be classified with the <classval> specified. An example:

  classify 2:11 –p tcp --dport 22

The script works this out to

  iptables –t mangle –A POSTROUTING –p tcp –-dport 22 –-jump CLASSIFY --setclass 2:11

Should you want to also log the packet, you’d use

 classify 2:11 log –p tcp --dport 22

The script works this out to

  iptables –t mangle –A POSTROUTING –p tcp –-dport 22 –-jump LOG \
     --log-prefix classified_2:11:
  iptables –t mangle –A POSTROUTING –p tcp –-dport 22 –-jump CLASSIFY \
     --setclass 2:11

Should you not give a msg, then the log-prefix becomes POSTROUTING_CLASSIFY_set_<classval>. Because of how iptables handles the CLASSIFY target, you can only use it in contexts where the chain is “POSTROUTING” and the table is “mangle”.

Target keyword: drop

drop [log [msg <message>]] <qualifiers>
In essence, this does the same as the “accept” target keyword, only it jumps to DROP instead of ACCEPT. Thus any packet matching the qualifiers gets discarded; it will not get sent on to its final destination (or next hop), it will not get processed by any other firewall rule, and the sender of the packet is unaware of your treatment of his packet. Should you want to also log the packet, you’d use

context "FORWARD" "filter"
drop log –p tcp -s 10.0.0.0/16

The script works this out to

  iptables –t filter –A FORWARD –p tcp -s 10.0.0.0/16 –-jump LOG \
     --log-prefix FORWARD_DROP:
  iptables –t filter –A FORWARD –p tcp -s 10.0.0.0/16 –-jump DROP

Because of how iptables handles the DROP target, you can only use it in contexts where the table is “filter”.

Target keyword: mark

mark <markval> [log [msg <message>]] <qualifiers>
If a packet matches the qualifiers, then it will be marked with the <markval> specified. An example from the context “PREROUTING” “mangle”:

mark 2 –p tcp --dport 22

Iceditch works this out to

iptables –t mangle –A PREROUTING –p tcp –-dport 22 –-jump MARK --setmark 2

Should you want to also log the packet, you’d use

 mark 2 log –p tcp --dport 22

Iceditch works this out to

 iptables –t mangle –A PREROUTING –p tcp –-dport 22 –-jump LOG \
    --log-prefix PREROUTING_MARK_set_2:
 iptables –t mangle –A PREROUTING –p tcp –-dport 22 –-jump MARK --setmark 2

Because of how iptables handles the MARK target, you can only use it in contexts where the table is “mangle”.

Target keyword: redirect

redirect [to <to-ports>] [log [msg <message>]] <qualifiers>
If a packet matches the qualifiers, then it will be redirected to the local machine, by setting the destination IP to a fitting IP address of the local machine (i.e. 127.0.0.1, or the first-bound IP address of the interface over which it came in. Additionally, by specifying “to <to-ports>” you can have the destination ports redirected to a port or portrange. <to-ports> can either be a port number (e.g. 8080) or a port range (e.g. 6661-6669; the latter is inclusive). Example for a transparent HTTP proxy:

context "OUTPUT" "nat"
redirect to 8080 –p tcp --dport 80

Iceditch works this out to

 iptables –t nat –A OUTPUT –p tcp –-dport 80 –-jump REDIRECT –to-ports 8080

Should you want to log the packet, you could use

 redirect to 8080 log –p tcp --dport 80

Iceditch works this out to

 iptables –t nat –A OUTPUT –p tcp –-dport 80 –-jump LOG \
    --log-prefix OUTPUT_REDIRECT_to_8080:
 iptables –t nat –A OUTPUT –p tcp –-dport 80 –-jump REDIRECT –-to-ports 8080

Because of how iptables handles the REDIRECT target, you can only use it in contexts where the table is “nat” and the chain is PREROUTING or OUTPUT.

Target keyword: reject

reject [with <type>] [log [msg <message>]] <qualifiers>
In essence, this does the same as the “drop” target keyword, only it jumps to REJECT instead of DROP. This means the packet is discarded (just as with DROP), but the sender is notified using ICMP (by default, your machine will send an ICMP-packet of type "icmp-port-unreachable"). Because of how iptables handles the REJECT target, you can only use it in contexts where the table is “filter”. Optionally, you can follow “reject” with the keyword “with”, and then use one of the following rejection types:

Type	Description
icmp-host-prohibited	will send an ICMP-message "host prohibited"
icmp-host-unreachable	will send an ICMP-message "host unreachable"
icmp-net-prohibited	will send an ICMP-message "net prohibited"
icmp-net-unreachable	will send an ICMP-message "net unreachable"
icmp-port-unreachable	DEFAULT; will send an ICMP-message "port unreachable"
icmp-proto-unreachable	DEFAULT; will send an ICMP-message "protocol unreachable"
tcp-reset	will send a TCP reset, a packet with the RST flag set (as a response to a TCP packet only)
host-prohib	synonymous to icmp-host-prohibited
host-unreach	synonymous to icmp-host-unreachable
net-prohib	synonymous to icmp-net-prohibited
net-unreach	synonymous to icmp-net-unreachable
port-unreach	synonymous to icmp-port-unreachable
proto-unreach	synonymous to icmp-proto-unreachable

If you don’t specify “with <type>”, then netfilter will assume icmp-port-unreachable. Thus, should you want to reject a packet in context filter_INPUT (and log it) with reason net-prohib, you’d use

 reject with net-prohib log –p tcp –i eth0 --dport 22

Iceditch works this out to

 iptables –t filter –A INPUT –p tcp –i eth0 –-dport 22 –-jump LOG \
   --log-prefix INPUT_REJECT_with_net-prohib:
 iptables –t filter –A INPUT –p tcp –i eth0 –-dport 22 \
   –-jump REJECT –-reject-with net-prohib –p tcp –i eth0 –-dport 22