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 and all the other default setting of the "log" target. Should you want to log a packet with more control over the logging parameters, then you need 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 msg Secure_Shell –p tcp --dport 22

Iceditch works this out to

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

You can easily see that “accept log msg Secure_Shell –p tcp --dport 22” is much more readable... Note: because of how IPtables handles the ACCEPT target, you can only use it in contexts where the table is “filter”.

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. Because of how iptables handles the DROP target, you can only use it in contexts where the table is “filter”.

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-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-prohibited	will send an ICMP-message "port prohibited"
icmp-port-unreachable	DEFAULT; will send an ICMP-message "port 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

The script 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

Surely the rule in the script is more readable…