Iceditch Command Reference - Revision history

Saruman!: Reverted edits by 85.17.90.205 (Talk) to last revision by Saruman!

2010-07-06T17:42:18Z

Reverted edits by 85.17.90.205 (Talk) to last revision by Saruman!

← Older revision		Revision as of 19:42, 6 July 2010
Line 1:		Line 1:
	<a ~~href=~~"~~http:~~/~~/sumerki3~~.~~net/~~">~~�� 3~~</a>		== Parameter: log ==
			''target '''log [(msg\|message) <message>]''' <matches>''<br>
			After most keywords, a "log" parameter can be added (see below). If the "log" parameter is followed by "msg" (or "message"), then the parameter following "msg" is read and used as log-prefix. The parameter is not allowed to have whitespace (that limitation is Iceditch-specific, not IPtables-related), and the maximum length of the log-prefix is determined by your version of netfilter/IPtables and your choice of IPtables logging utility (syslogemu or ulog); this limit is usually some 29 characters. Note that Iceditch does not perform any sanity checks on the message.

			Thus a packet matching the <matches> part of 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 a default log message, being "<table>_<chain>_<target>" 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 [[Iceditch_Command_Reference#Target_keyword:_log \| target keyword "log"]] below.

	== Context keyword: context ==		== Context keyword: context ==

85.17.90.205: /* Parameter: log */

2010-06-29T23:56:31Z

Parameter: log

← Older revision		Revision as of 01:56, 30 June 2010
Line 1:		Line 1:
	~~== Parameter: log ==~~		<a href="http://sumerki3.net/">�� 3</a>
	~~''target '''log [(msg\|message)~~ <~~message>]''' <matches>''<br>~~
	~~After most keywords,~~ a "~~log" parameter can be added (see below)~~. If the "log" parameter is followed by "msg" (or "message"), then the parameter following "msg" is read and used as log-prefix. The parameter is not allowed to have whitespace (that limitation is Iceditch-specific, not IPtables-related), and the maximum length of the log-prefix is determined by your version of netfilter/~~IPtables and your choice of IPtables logging utility (syslogemu or ulog); this limit is usually some 29 characters. Note that Iceditch does not perform any sanity checks on the message.~~

	~~Thus a packet matching the <matches> part of 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 a default log message, being "<table>_<chain~~>_<~~target~~>" 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 [[Iceditch_Command_Reference#Target_keyword:_log \| target keyword "log"]] below.

	== Context keyword: context ==		== Context keyword: context ==

Saruman!: /* Target keyword: connmark */ corrected max mark value

2008-08-15T20:53:52Z

Target keyword: connmark: corrected max mark value

← Older revision		Revision as of 22:53, 15 August 2008
Line 49:		Line 49:
	== Target keyword: connmark ==		== Target keyword: connmark ==
	'''''connmark { set <val>[/<mask>] \| save [mask <mask>] \| restore [mask <mask>] } [log [msg <message>]] <matches>'''''<br>		'''''connmark { set <val>[/<mask>] \| save [mask <mask>] \| restore [mask <mask>] } [log [msg <message>]] <matches>'''''<br>
	This target sets a mark on a connection when you use ''connmark set <value>''; the mark for your connection is the specified <value>, or <value> ANDed with <mask>. The resulting mark value is an integer between 0 and ~~4294967295l~~, so you can set plenty of matches :-). The marks you set can be matched in different rules with the "connmark match", so this is a bit like a bookmark.<br>		This target sets a mark on a connection when you use ''connmark set <value>''; the mark for your connection is the specified <value>, or <value> ANDed with <mask>. The resulting mark value is an integer between 0 and 4,294,967,295, so you can set plenty of matches :-). The marks you set can be matched in different rules with the "connmark match", so this is a bit like a bookmark.<br>
	Now sometimes you have already marked a packet with the MARK target; you can subsequently push this MARK-value through to the connection using ''conmark save'', although you can slightly alter the connection mark value using the ''mask <mask>'' option, which provides a binary "and", so that only the masked bits are set.<br>		Now sometimes you have already marked a packet with the MARK target; you can subsequently push this MARK-value through to the connection using ''conmark save'', although you can slightly alter the connection mark value using the ''mask <mask>'' option, which provides a binary "and", so that only the masked bits are set.<br>
	This process also works the other way around: you can "restore" the mark on the connection to an individual packet using ''restore'', if need be again logically ANDed with a <mask> value. However, this last action works '''only''' in the ''mangle'' table (naturally, since it mangles the packet).<br>		This process also works the other way around: you can "restore" the mark on the connection to an individual packet using ''restore'', if need be again logically ANDed with a <mask> value. However, this last action works '''only''' in the ''mangle'' table (naturally, since it mangles the packet).<br>

Saruman!: /* Target keyword: connmark */ started

2008-08-15T20:28:53Z

Target keyword: connmark: started

@@ Line 46: / Line 46: @@
    iptables –t filter –A INPUT –p tcp –-dport 22 –-jump ACCEPT
 Note: the ACCEPT target is valid in any user-manipulable table/chain combination
 == Target keyword: classify ==

Saruman!: /* Target keyword: reject */ added RFC behaviour

2008-08-15T05:53:25Z

Target keyword: reject: added RFC behaviour

← Older revision		Revision as of 07:53, 15 August 2008
Line 325:		Line 325:
	iptables –t filter –A INPUT –p tcp –i eth0 –-dport 22 \		iptables –t filter –A INPUT –p tcp –i eth0 –-dport 22 \
	–-jump REJECT –-reject-with net-prohib –p tcp –i eth0 –-dport 22		–-jump REJECT –-reject-with net-prohib –p tcp –i eth0 –-dport 22
			Note: RFC behavior is that unbound TCP ports return resets on connections, and unbound UDP ports return ICMP port unreachable. If you want to make your firewall less obtrusive, then do that. Your filtered ports will then be (at least in that respect) indistinguishable from unfiltered, unbound ports.

	==Target keyword: route==		==Target keyword: route==

Saruman!: /* Target keyword: nojump */ started

2008-08-14T17:23:15Z

Target keyword: nojump: started

@@ Line 232: / Line 232: @@
 It is still possible to use the MASQUERADE target instead of SNAT even though you do have a static IP; however, it is not favorable since it will add extra overhead, and there may be inconsistencies in the future which will thwart your existing scripts and render them "unusable".<br>
 Note that the MASQUERADE target is only valid within the POSTROUTING chain in the nat table, just as the SNAT target.
 == Target keyword: redirect ==

Saruman!: /* Target keyword: log */ clarified difference log/ulog

2008-08-12T06:23:54Z

Target keyword: log: clarified difference log/ulog

← Older revision		Revision as of 08:23, 12 August 2008
Line 104:		Line 104:
	''for ULOG target: '''log [(msg\|message) <message>] [cprange <range>] [qtreshold\|qtresh <treshold>] <matches>'''''		''for ULOG target: '''log [(msg\|message) <message>] [cprange <range>] [qtreshold\|qtresh <treshold>] <matches>'''''

	Sometimes, the standard ''log'' parameter is just not enough. This can be the case when you want to log a packet ~~to a log-level other than~~ the ~~default level, which for most systems is~~ ''~~4'' ('~~'~~warning~~''). ~~Furthermore,~~ maybe you want to log a certain type or class of packets, without performing an action on those packets just yet. For this reason, AND for flexibility and clarity, Iceditch has the dedicated target keyword ''log''.<br>		Sometimes, the standard ''log'' parameter is just not enough. This can be the case when you want to log a packet with one or more of the extra options beside ''--log-prefix''. Or maybe you want to just log a certain type or class of packets, without performing an action on those packets just yet, so that you can't use ''log'' as a parameter to one of the other Iceditch keywords.<br>
	Just as when you use the ''log'' parameter after another target keyword, Iceditch ~~will~~ call the ~~log target~~ specified in the Iceditch [[Iceditch file structure \| config file]]. Standard this is LOG, but optionally you could specify ULOG in the config file. Note~~, however,~~ that an explicit call on target keyword ''log'' gives one the option to specify extra ~~parameter. Note~~ also, that the choice of parameters ~~to specify~~ depends on your choice of logging daemon~~, as specified in the [[Iceditch file structure \| config file]]~~.		For this reason, AND for flexibility and clarity, Iceditch has the dedicated target keyword ''log''.<br>
			Just as when you use the ''log'' '''parameter''' after another target keyword, the use of the log '''target''' will make Iceditch call upon the logging daemon specified in the Iceditch [[Iceditch file structure \| config file]]. Standard this is LOG, but optionally you could specify ULOG in the config file. Note that an explicit call on target keyword ''log'' gives one the option to specify extra parameters, but also note that the choice of which parameters you can use depends on your configured choice of logging daemon.

	=== ~~the~~ message to log ===		=== The message to log ===
	Now the message that gets logged is treated the same by Iceditch, no matter which logging daemon you use. Somewhere after the target keyword ''log'' (but before any of the <matches> you specify ''msg <message>'' (or ''message <message>). The ''<message>'' can be any string between 1 and some 29 characters max (letters, numbers and underscores; no spaces, not empty). If you do NOT specify a message, Iceditch will always create a default log message: ''<chain>_<table>_log''. This means that		Now the message that gets logged is treated the same by Iceditch, no matter which logging daemon you use. Somewhere after the target keyword ''log'' (but before any of the <''matches''>) you specify ''msg <message>'' (or ''message <message>''). The ''<message>'' can be any string between 1 and some 29 characters max (letters, numbers and underscores; no spaces, not empty). If you do NOT specify a message, Iceditch will always create a default log message: ''<chain>_<table>_log''. This means that
	<pre>context INPUT filter		<pre>context INPUT filter
	log -p tcp --dport 22		log -p tcp --dport 22
Line 118:		Line 119:
	(note the default log level when using the ''syslog'' logging daemon).		(note the default log level when using the ''syslog'' logging daemon).

	=== ~~log~~ parameters when using the ''syslog'' logging daemon===		=== Log parameters when using the ''syslog'' logging daemon===
	Besides a log message, there are four more options that you can also specify. All five options are shown in the table below:		Besides a log message, there are four more options that you can also specify. All five options are shown in the table below:
	{\| 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 181:		Line 182:
	\|}		\|}

	=== ~~log~~ parameters when using the ''ulog'' user space logging daemon===		=== Log parameters when using the ''ulog'' user space logging daemon===
	{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"		{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"
	! colspan="3" style="background:#ffdead;"\|ULOG options		! colspan="3" style="background:#ffdead;"\|ULOG options
Line 192:		Line 193:
	\| --ulog-cprange <''size''>		\| --ulog-cprange <''size''>
	\|log the first ''size'' bytes of each packet		\|log the first ''size'' bytes of each packet
			\|-
			\| msg / message <''logmessage''>
			\| --log-prefix <''logmessage''>
			\| Makes Netfilter prepend <''logmessage''> to the log entry
	\|-		\|-
	\| qtreshold / qtresh <''value''>		\| qtreshold / qtresh <''value''>

Saruman!: /* log parameters when using the ''syslog'' logging daemon */ edited option table

2008-08-12T06:09:54Z

log parameters when using the ''syslog'' logging daemon: edited option table

← Older revision		Revision as of 08:09, 12 August 2008
Line 119:		Line 119:

	=== log parameters when using the ''syslog'' logging daemon===		=== log parameters when using the ''syslog'' logging daemon===
	Besides a log message, there are four options that you can also specify. ~~These~~ are shown in the table below:		Besides a log message, there are four more options that you can also specify. All five options are shown in the table below:
	{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"		{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"
	! colspan="3" style="background:#ffdead;"\|LOG options		! colspan="3" style="background:#ffdead;"\|LOG options
Line 131:		Line 131:
	\|Makes Netfilter include the IP options in the log entry		\|Makes Netfilter include the IP options in the log entry
	\|-		\|-
	\| lvl / level <loglevel>		\| lvl / level <''loglevel''>
	\| --log-level		\| --log-level <''loglevel''>
	\| Makes Netfilter log with the specified ~~level~~		\| Makes Netfilter log with the specified <''loglevel''>
			\|-
			\| msg / message <''logmessage''>
			\| --log-prefix <''logmessage''>
			\| Makes Netfilter prepend <''logmessage''> to the log entry
	\|-		\|-
	\| tcp-options / tcpopt		\| tcp-options / tcpopt

Saruman!: /* Target keyword: log */ split between LOG and ULOG

2008-08-11T22:35:16Z

Target keyword: log: split between LOG and ULOG

← Older revision		Revision as of 00:35, 12 August 2008
Line 101:		Line 101:

	== Target keyword: log ==		== Target keyword: log ==
	'''''log [(msg\|message) <message>] [(lvl\|level) <loglevel>] <matches>'''''<br>		''for LOG target: '''log [(msg\|message) <message>] [ip-options\|ipopt] [(lvl\|level) <loglevel>] [tcp-options\|tcpopt] [tcp-sequence\|tcpseq] <matches>'''''<br>
			''for ULOG target: '''log [(msg\|message) <message>] [cprange <range>] [qtreshold\|qtresh <treshold>] <matches>'''''

	Sometimes, the standard ''log'' parameter is just not enough. This can be the case when you want to log a packet to a log-level other than the default level, which for most systems is ''4'' (''warning''). Furthermore, maybe you want to log a certain type or class of packets, without performing an action on those packets just yet. For this reason, AND for flexibility and clarity, Iceditch has the dedicated target keyword ''log''.<br>		Sometimes, the standard ''log'' parameter is just not enough. This can be the case when you want to log a packet to a log-level other than the default level, which for most systems is ''4'' (''warning''). Furthermore, maybe you want to log a certain type or class of packets, without performing an action on those packets just yet. For this reason, AND for flexibility and clarity, Iceditch has the dedicated target keyword ''log''.<br>
	Just as when you use the ''log'' parameter after another target, Iceditch will call the log target specified in the Iceditch [[Iceditch file structure \| config file]]. Standard this is LOG, but optionally you could specify ULOG in the config file.		Just as when you use the ''log'' parameter after another target keyword, Iceditch will call the log target specified in the Iceditch [[Iceditch file structure \| config file]]. Standard this is LOG, but optionally you could specify ULOG in the config file. Note, however, that an explicit call on target keyword ''log'' gives one the option to specify extra parameter. Note also, that the choice of parameters to specify depends on your choice of logging daemon, as specified in the [[Iceditch file structure \| config file]].
	''<message>'' can be any string ~~of 32~~ characters max (letters, numbers and underscores; no spaces)~~; the~~ ''<~~loglevel~~>'' ~~can~~ either ~~be numeric or~~ the ~~corresponding keyword~~ (~~e.g.~~ ''~~crit~~'')~~; Iceditch translates it to its numeric value anyway~~. ~~Furthermore, the order in which <msg> and <lvl> appear is not important.<br>~~
	~~Depending on which~~ log ~~target you have specified, there are some options you can use with~~ the ~~Iceditch target keyword~~ ''~~log~~''~~; it is currently deemed unnecessary to make specific Iceditch parameters for them~~, ~~but as a reference we'll list the official IPtables~~ options ~~here, which~~ you can ~~put~~ in ~~with~~ the ~~<matches> list~~:		=== the message to log ===
			Now the message that gets logged is treated the same by Iceditch, no matter which logging daemon you use. Somewhere after the target keyword ''log'' (but before any of the <matches> you specify ''msg <message>'' (or ''message <message>). The ''<message>'' can be any string between 1 and some 29 characters max (letters, numbers and underscores; no spaces, not empty). If you do NOT specify a message, Iceditch will always create a default log message: ''<chain>_<table>_log''. This means that
			<pre>context INPUT filter
			log -p tcp --dport 22
			</pre>
			will result in either one of the iptables lines shown below, depending on your choice of logging daemon:
			<pre>iptables -A INPUT -t filter -p tcp --dport 22 --jump LOG --log-prefix INPUT_filter_log --log-level 4
			iptables -A INPUT -t filter -p tcp --dport 22 --jump ULOG --ulog-prefix INPUT_filter_log
			</pre>
			(note the default log level when using the ''syslog'' logging daemon).

			=== log parameters when using the ''syslog'' logging daemon===
			Besides a log message, there are four options that you can also specify. These are shown in the table below:
	{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"		{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"
	! colspan="2" style="background:#ffdead;"\|LOG ~~options~~		! colspan="3" style="background:#ffdead;"\|LOG options
	\|
	~~! colspan="2" style="background:#ffdead;"\|ULOG~~ options
	\|-		\|-
	!style="background:#ffdead;"\|~~Option~~		!style="background:#ffdead;"\|Iceditch option
	!style="background:#ffdead;"\|~~Description~~		!style="background:#ffdead;"\|IPtables option
	\|
	~~!style="background:#ffdead;"\|Option~~
	!style="background:#ffdead;"\|Description		!style="background:#ffdead;"\|Description
	\|-		\|-
			\|ip-options / ipopt
	\| --log-ip-options		\| --log-ip-options
	\|Makes Netfilter include the IP options in the log entry		\|Makes Netfilter include the IP options in the log entry
	\|
	~~\| --ulog-cprange <''size''>~~
	~~\|log the first ''size'' bytes of each packet~~
	\|-		\|-
			\| lvl / level <loglevel>
			\| --log-level
			\| Makes Netfilter log with the specified level
			\|-
			\| tcp-options / tcpopt
	\| --log-tcp-options		\| --log-tcp-options
	\|Makes Netfilter include the TCP options in the log entry		\|Makes Netfilter include the TCP options in the log entry
	\|
	~~\| --ulog-nlgroup <''nlgroup''>~~
	~~\|Log to Netlink group number ''nlgroup'' (must match ''/etc/ulogd.conf'')~~
	\|-		\|-
			\| tcp-sequence / tcpseq
	\| --log-tcp-sequence		\| --log-tcp-sequence
	\|Makes Netfilter include the TCP sequence number in the log entry		\|Makes Netfilter include the TCP sequence number in the log entry
	\|
	~~\| --ulog-qthreshold <''value''>~~
	~~\|Queue ''value'' packets before sending them to ''ulogd'' (default = 1, max = 50)~~
	\|-		\|-
	\|}		\|}
	~~<br>~~
	For completeness, we here reproduce the list of logging levels that ''log'' understands:		On the log-level: when using the ''syslog'' daemon (IPtables target LOG), it is possible to specify a log level. The log level can be specified numerically or by name; Iceditch will translate it to its numerical value. However, if you do NOT specify a log level, Iceditch will include a default log level, being 4 (warn). For completeness, we here reproduce the list of logging levels that ''log'' understands:
	{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"		{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"
	!style="background:#ffdead;"\|Level		!style="background:#ffdead;"\|Level
Line 168:		Line 176:

	\|}		\|}

			=== log parameters when using the ''ulog'' user space logging daemon===
			{\| class="wikitable" style="text-align:center" border="1" cellspacing="0" cellpadding="5"
			! colspan="3" style="background:#ffdead;"\|ULOG options
			\|-
			!style="background:#ffdead;"\|Iceditch option
			!style="background:#ffdead;"\|IPtables option
			!style="background:#ffdead;"\|Description
			\|-
			\| cprange <''size''>
			\| --ulog-cprange <''size''>
			\|log the first ''size'' bytes of each packet
			\|-
			\| qtreshold / qtresh <''value''>
			\| --ulog-qthreshold <''value''>
			\|Queue ''value'' packets before sending them to ''ulogd'' (default = 1, max = 50)
			\|-
			\|}
			<br>

	Now an example:		Now an example:
	context "INPUT" "filter"		context "INPUT" "filter"

Saruman!: /* Parameter: log */ added link

2008-08-11T21:49:35Z

Parameter: log: added link

← Older revision		Revision as of 23:49, 11 August 2008
Line 1:		Line 1:
	== Parameter: log ==		== Parameter: log ==
	''target '''log [(msg\|message) <message>]''' <matches>''<br>		''target '''log [(msg\|message) <message>]''' <matches>''<br>
	After most keywords, a "log" parameter can be added (see below). If the "log" parameter is followed by "msg" (or "message"), then the parameter following "msg" is read and used as log-prefix. The parameter is not allowed to have whitespace (that limitation is Iceditch-specific, not IPtables-related), and the maximum length of the log-prefix is determined by your version of netfilter/IPtables and your IPtables logging utility (syslogemu or ulog); this limit is usually some 29 characters. Note that Iceditch does not perform any sanity checks on the message.		After most keywords, a "log" parameter can be added (see below). If the "log" parameter is followed by "msg" (or "message"), then the parameter following "msg" is read and used as log-prefix. The parameter is not allowed to have whitespace (that limitation is Iceditch-specific, not IPtables-related), and the maximum length of the log-prefix is determined by your version of netfilter/IPtables and your choice of IPtables logging utility (syslogemu or ulog); this limit is usually some 29 characters. Note that Iceditch does not perform any sanity checks on the message.

	Thus a packet matching the <matches> part of the rule will be logged with the default setting of the "log" target.		Thus a packet matching the <matches> part of 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 a default log message, being "<table>_<chain>_<target>" 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.		If the "log" parameter is ''not'' followed by "msg", then the packet will be logged with a default log message, being "<table>_<chain>_<target>" 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 [[Iceditch_Command_Reference#Target_keyword:_log \| target keyword "log"]] below.

	== Context keyword: context ==		== Context keyword: context ==