{ package IPTables; use IPTables::IPv4::Toplevel; %IPv4; tie(%IPv4, 'IPTables::IPv4::Toplevel'); } package IPTables::IPv4; use strict; use Carp; use vars qw($VERSION @ISA @EXPORT @EXPORT_OK $AUTOLOAD); require Exporter; require DynaLoader; require AutoLoader; @ISA = qw(Exporter DynaLoader); # Items to export into callers namespace by default. Note: do not export # names by default without a very good reason. Use EXPORT_OK instead. # Do not simply export all your public functions/methods/constants. @EXPORT = qw( ); $VERSION = '0.98'; sub AUTOLOAD { # This AUTOLOAD is used to 'autoload' constants from the constant() # XS function. If a constant is not found then control is passed # to the AUTOLOAD in AutoLoader. my $constname; ($constname = $AUTOLOAD) =~ s/.*:://; croak "& not defined" if $constname eq 'constant'; my $val = constant($constname, @_ ? $_[0] : 0); if ($! != 0) { if ($! =~ /Invalid/) { $AutoLoader::AUTOLOAD = $AUTOLOAD; goto &AutoLoader::AUTOLOAD; } else { croak "Your vendor has not defined IPTables macro $constname"; } } no strict 'refs'; *$AUTOLOAD = sub () { $val }; goto &$AUTOLOAD; } bootstrap IPTables::IPv4 $VERSION; # Preloaded methods go here. # Autoload methods go after =cut, and are processed by the autosplit program. 1; __END__ # Below is the stub of documentation for your module. You better edit it! =head1 NAME IPTables::IPv4 - Perl module for manipulating iptables rules for the IPv4 protocol =head1 SYNOPSIS use IPTables::IPv4; $table = IPTables::IPv4::init('tablename'); %IPTables::IPv4 = ( filter => { INPUT => { rules => [ { source => '10.0.0.0/8', jump => 'ACCEPT' } ], pcnt => 50000, bcnt => 1000000, policy => 'DROP' } } ); =head1 DESCRIPTION This package provides a nice interface to the IP Tables control API that fairly closely parallels the C API exported in libiptc for manipulating firewalling and forwarding rules for IPv4 packets. Also, a tied multilayer data structure has been built, allowing the tables, chains, rules and fields to be manipulated in a more natural fashion. Wrappers have been implemented for all methods except one (C), and according to Harald Welte and Rusty Russell, the unimplemented call will likely remain so. Protocol-specific match modules have been implemented for TCP, UDP and ICMP. Several target and non-protocol match modules have been implemented. The module will be built with a default library path built into it. That can be overridden using the IPT_IPV4_MODPATH environment variable. If your script is being called suid root, you may want to do C to ensure that someone isn't subverting your script. Make sure you do this before you C to ensure that it never loads from an unapproved path. =head1 METHODS Most methods will return 1 for success, or 0 for failure (and on failure, set $! to a string describing the reason for the failure). Unless otherwise noted, you can assume that all methods will use this convention. =head2 Initialization =over =item $table = IPTables::IPv4::init('tablename') This sets up the connection to the kernel-level netfilter subsystem. C corresponds to the name of a table (C, C, C, or C) to manipulate. The call returns an object of type IPTables::IPv4::Table, which all the other methods are to be called against, if the named table exists. If it does not exist, C will be returned. =back =head2 Chain Operations =over =item $is_builtin = $table-Ebuiltin('chainname') This checks if the chain C is built into the current table. The method will return 1 if C is a built-in chain, or 0 if it is not. =item $success = $table-Ecreate_chain('chainname') This attempts to create the chain C. =item $success = $table-Edelete_chain('chainname') This attempts to delete the chain C. =item ($policy, $pcnt, $bcnt) = $table-Eget_policy('chainname') This returns an array containing the default policy, and the number of packets and bytes which have reached the default policy, in the chain C. If C does not exist, or if it is not a built-in chain, an empty array will be returned, and $! will be set to a string containing the reason. =item $refcnt = $table-Eget_references('chainname') This returns the reference count for the chain C if it exists and is a user-defined chain. If C does not exist, or is a built-in chain, -1 will be returned, and $! will be set to a string containing the reason. =item $is_chain = $table-Eis_chain('chainname') This checks to verify that the chain C exists in the current table. The method will return 1 if C is a chain, 0 if not. =item @chains = $table-Elist_chains() In array context, this method returns an array containing names of all existing chains in the table that C<$table> points to. In scalar context, returns the number of chains in the table. =item $success = $table-Erename_chain('oldname', 'newname') This attempts to rename the chain C to C. =item $success = $table-Eset_policy('chainname', 'target') =item $success = $table-Eset_policy('chainname', 'target', {pcnt =E count, bcnt =E count}) This attempts to set the default target for the chain C to C. It also allows the packet and byte counters on a chain to be set using the (optional) third argument. Those values must be passed as a hash ref, as shown. =back =head2 Rule Operations =over =item $success = $table-Eappend_entry('chainname', $hashref) This attempts to append the rule described in the hash referenced by C<$hashref> to the chain C. =item $success = $table-Edelete_entry('chainname', $hashref) This attempts to delete a rule matching that described in the hash referenced by C<$hashref> from the chain C. =item $success = $table-Edelete_num_entry('chainname', $rulenum) This attempts to delete the rule C<$rulenum> from the chain C. =item $success = $table-Eflush_entries('chainname') This deletes all rules from the chain C. =item $success = $table-Einsert_entry('chainname', $hashref, $rulenum) This attempts to insert the rule described in the hash referenced by C<$hashref> at index C<$rulenum> in the chain C. =item @rules = $table-Elist_rules('chainname') When called in array context, this method returns an array of hash references, which contain descriptions of each rule in the chain C. In scalar context, returns the number of rules in the chain. Note that if the chain C does not exist, an empty list will be returned, as will listing an empty chain. Be sure to verify that the chain exists I you try to list the rules. =item $success = $table-Ereplace_entry('chainname', $hashref, $rulenum) This attempts to replace the rule at index C<$rulenum> in the chain C with the rule described in the hash referenced by C<$hashref>. =item $success = $table-Ezero_entries('chainname') This zeroes all packet counters in the chain C. =back =head2 Cleanup =over =item $success = $table-Ecommit() This attempts to commit all changes made to the IP chains in the table that C<$table> points to, and closes the connection to the kernel-level netfilter subsystem. If you wish to apply your changes back to the kernel, you must call this. =back =head1 RULE STRUCTURE The rules in the libiptc interface are expressed as Cs. However, I have decided to express the rules as hashes. The rules are passed around as hash references, and may contain the following fields: =over =item source The source address of a packet. This will appear in one of the following forms: ip.add.re.ss ip.add.re.ss/maskwidth ip.add.re.ss/ne.t.ma.sk It may be prefixed with a '!', to indicate the inverse sense of the address (i.e., match anything EXCEPT the address or address range specified). =item destination The destination address of a packet. It will appear in one of the same forms as C (see above). =item in-interface The network device which received the packet. Some chains cannot accept a rule with C set (such as the C chain). This may show up as a full interface name (such as C), or as a wildcarded interface name (such as C, where C<+> is the wildcard character, which can only be used at the end of a wildcarded interface string). It may be prefixed with a '!', to indicate the inverse sense of the interface (i.e., match anything EXCEPT the interface specified). =item out-interface The network device that a packet will be sent out via. Some chains cannot accept a rule with C set (such as the C chain). The format is the same as that for C (see above). =item protocol The name of the protocol of an incoming packet. It may be prefixed with a '!', to indicate the inverse sense of the protocol (i.e., match anything EXCEPT this protocol). =item fragment An integer value. 1 indicates the rule should match only fragments, 0 indicates the rule should not match any fragments. Don't set this unless you really want to either match all or no fragments. =item jump The target or chain to jump to if the rule matches. =item pcnt/bcnt The number of packets and bytes that have matched this rule since the rule was put in place, or since its counters were last zeroed. =item matches An array reference, containing a list of all the match modules which are to be used as part of the rule. Any match qualifier other than a protocol match module - i.e., C, C, C, etc., must be specified with this option, or any fields that belong to them will not be honored. =item [target]-target-raw This contains, as a string, the raw target data for a rule, if the needed module can't be found. I<[target]> should be the name of the target. There will, of course, only be one of these per rule (as each rule can only have one target). =item [match]-match-raw This contains, as a string, the raw match data for a rule, if the needed module can't be found. I<[match]> should be the name of the match. There can be more than one of these in one rule. If a match is specified in C, and no match module is available, raw data must be provided. =back =head1 MODULE-SPECIFIC RULE OPTIONS Each module, for protocols, non-protocol matches, and non-standard targets, has specific keys associated with specific options. =head2 TCP protocol options =over =item source-port The port, or range of ports (separated by a colon), that a packet is expected to come from. It can be passed as an integer, or a string. The ports may be designated by number, or by name, if the name is in F. Its value can be prefixed with an '!' to denote inverted sense. =item destination-port The port, or range of ports (separated by a colon), that a packet is expected to go to. It can be passed as an integer, or a string. The ports may be designated by number, or by name, if the name is in F. Its value can be prefixed with an '!' to denote inverted sense. =item tcp-flags The TCP packet flags to mask for and to compare against. It is expressed as a hash reference, containing the following keys: =over =item C The bits to AND the TCP flags with. This expresses the flags we care about. These are expressed as an array reference, containing one or more of the TCP flag names (C, C, C, C, C, and C), or the special names C or C. =item comp The bits which must be set among those which are part of the mask. If a TCP flag is listed in the mask, but not here, then it must be cleared. These are expressed as in the C field. =item inv Invert the sense of the TCP flag check. If this key exists in the hash, it will invert the sense of the flag check - the value is not checked. =back =item tcp-option The TCP option number to check for. It can be passed as an integer, or a string. Its value can be prefixed with an '!' to denote inverted sense. =back =head2 UDP protocol options =over =item source-port The port, or range of ports (separated by a colon), that a packet is expected to come from. It can be passed as an integer, or a string. The ports may be designated by number, or by name, if the name is in F. Its value can be prefixed with an '!' to denote inverted sense. =item destination-port The port, or range of ports (separated by a colon), that a packet is expected to go to. It can be passed as an integer, or a string. The ports may be designated by number, or by name, if the name is in F. Its value can be prefixed with an '!' to denote inverted sense. =back =head2 ICMP protocol options =over =item icmp-type The ICMP packet type to match. This can be passed as one of the named ICMP types, or in one of the following forms: typenum typenum/codenum typenum/codemin-codemax The value can be prefixed with an '!' to denote inverse sense. =back =head2 dscp match options This match will allow a rule to match the Differentiated Services code-point field in the IP headers of incoming packets. Only one of the following options may be used in any one rule. DSCP supplants TOS as a mechanism for indicating the type of service being provided by a packet stream. =over =item dscp Specify the numeric Differentiated Services value explicitly. The value may be prefixed with a '!' to indicate inverse sense. =item dscp-class Specify a named Differentiated Services class. This can be one of BE, EF, CS0-CS7, AF11-AF13, AF21-AF23, AF31-AF33, AF41-AF43. The value may be prefixed with a '!' to indicate inverse sense. =back =head2 iplimit match options This match allows a rule to match on the number of simultaneous TCP connections from individual hosts, or groups of hosts. The C field is required for this match. =over =item iplimit-above Specify the minimum number of TCP connections which will activate this match. This must be a positive integer value. It can be passed as an integer or string. The value can be prefixed with a '!' to indicate inverse sense (i.e. match on no more than the specified number). =item iplimit-mask Specify a mask width to group the matches by. This can be used to group connections by subnet. This can only be an integer, from 0 to 32, inclusive. The default is 32, which will count by individual IPs. =back =head2 ipv4options match options This match module allows a rule to match a packet based on certain IPv4 header flags. Only one of the source-routing flags may be set on any one rule, and the C flag will conflict with any of the other flags if they are set in an opposing fashion. =over =item ssrr Match packets with the strict source-routing flag set. The option's presence enables it. Its value is ignored. =item lsrr Match packets with the loose source-routing flag set. The option's presence enables it. Its value is ignored. =item no-srr Match packets with no source-routing flags set. The option's presence enables it. Its value is ignored. =item rr Match packets with, or without, the record-route flag set. The value must be integer. A zero value means match packets without the flag, a nonzero value means match packets with the flag. =item ts Match packets with, or without, the timestamp flag set. The value must be integer. A zero value means match packets without the flag, a nonzero value means match packets with the flag. =item ra Match packets with, or without, the router-alert flag set. The value must be integer. A zero value means match packets without the flag, a nonzero value means match packets with the flag. =item any-opt Match packets with any flag, or no flags, set. The value must be integer. A zero value means match packets with no flags set, a nonzero values means match packets with any flag set. =back =head2 length match options The C match allows matching based on the payload size of a packet. =over =item length The packet length, or range of lengths, to match on. This value may be passed as an integer or a string. To specify a range, specify the minimum value first, followed by the maximum, separated by a colon (':') character. The value may be prefixed with a '!' to indicate inverse sense. =back =head2 limit match options The C match module allows matching based on number of packets received over a period of time (specified via the C field). =over =item limit This field expresses the packet rate limit in terms of count per unit time. If no time unit is specified, seconds are assumed. The time unit can be any of 'sec' (or 'second'), 'min' (or 'minute'), 'hour' (or 'hr'), or 'day'. If unit time is to be specified, the limit should be specified as 'count/unit', where C is the number of packets to accept, and C is one of the units specified above. =item limit-burst This field indicates the initial number of packets to match. As packets are received, an internal counter will be decremented. When it reaches zero, packets will no longer meet the match criteria. As time passes at the rate specified in the C field, the counter will be incremented up to this value. =back =head2 mac match options The C match module allows matching based on the source MAC address of a received packet. This match is only effective in the C chain of the C table, or the C chain of the C table, or a user-created chain linked from either of those chains. =over =item mac-source This field expresses the hardware Ethernet address to compare against an incoming packet's source MAC address. It should be passed as a string containing six hex bytes separated by colons. It can be prefixed with a '!' character, to indicate inverse sense. =back =head2 mark match options The C match module allows matching based on a previously-set packet mark value, or specific bits in the mark value (with a mask value). =over =item mark This field indicates what mark value, or what bits of a mark value, should be matched on. It may be specified as a full value, or as a value with a mask (in value/mask form). The mask and value may be in hex, decimal, or octal. This may be preceded by a '!' character, to indicate inverse sense. This field is required when the C match is used. =back =head2 mport match options The C match allows a list of single ports and/or port ranges to be used as part of the matching criteria for a rule. C must be specified as part of the C list, as documented above, to be used. Only one of the fields listed below may be used in a rule. The value for the field must be a reference to an array, containing port names, port numbers, or ranges consisting of a start and end, separated by a colon (':') character, specified as either port numbers or names (either may be used, mixing is allowed). =over =item ports This specifies ports to match as either the source or destination port of a packet. =item source-ports This specifies ports to match as source ports only. =item destination-ports This specifies ports to match as destination ports only. =back =head2 multiport match options The C match module allows a list of up to 15 individual ports to be specified as part of a rule. C must be specified as part of the C parameter, as documented above, in order to be used. Only one of the following options to C may be used at once. The list of ports must be passed as an array reference. The ports may be specified by name or by number. C will only work as part of rules that match either TCP or UDP protocol. =over =item ports This specifies ports to match as either the source or destination port of a packet. =item source-ports This specifies ports to match as source ports only. =item destination-ports This specifies ports to match as destination ports only. =back =head2 owner match options The C match module allows packets (in the C chain of the C table only) to be matched on which user, (primary) group, process ID or process group (session) ID is associated with them. C must be specified as part of the C parameter, as documented above, in order to be used. =over =item uid-owner This specifies the UID to match on. The parameter may be either a UID number, or an actual username. The parameter may be prefixed with a '!' to indicate inverse sense. =item gid-owner This specifies the GID to match on. The parameter may be either a GID number, or an actual group name. The parameter may be prefixed with a '!' to indicate inverse sense. =item pid-owner This specifies the PID to match on. The parameter may be prefixed with a '!' to indicate inverse sense. =item sid-owner This specifies the SID (or process group ID) to match on. The parameter may be prefixed with a '!' to indicate inverse sense. =back =head2 state match options The C match module allows stateful packet matching, using netfilter's conntrack system to match based on the state of a connection. C must be specified as part of the C parameter, as documented above, in order to be used. =over =item state This specifies which connection states to match on. This parameter must be passed as an array reference, containing scalar elements, consisting of one or more of the keywords C, C, C, and C. =back =head2 tcpmss match options This specifies a range of TCP Maximum Send Size values which a rule should accept. This match only applies to TCP packets. =over =item mss The Maximum Send Size value, or range of values, to match on. This value may be passed as an integer or a string. To specify a range, specify the minimum value first, followed by the maximum, separated by a colon (':') character. The value may be prefixed with a '!' to indicate inverse sense. =back =head2 tos match options The C match allows matching based on Type of Service flags. (Note that TOS is deprecated in preference to DSCP.) =over =item tos This specifies which Type of Service flag to match on. The Type of Service values include 'Normal-Service' (1), 'Minimize-Cost' (2), 'Maximize-Reliability' (4), 'Maximize-Throughput' (8), and 'Minimize-Delay' (16). Only one of these may be used at a time. The TOS value may be specified as a string or a number, and only these known TOS values will be accepted. This field is required when the C match is used. =back =head2 ttl match options The C match allows matching based on the TTL (Time to Live) values of packets. One of the fields listed below is required, but only one may be used per rule. =over =item ttl-eq This field specifies an exact Time to Live value to match on. The value may be specified as a string or a number. It may be prefixed with a '!' character to denote inverse sense (i.e., anything not equal to the specified value). =item ttl-gt This field specifies a minimum Time to Live value to match on, i.e., only values greater than the one passed as part of this field, will be matched. The value may be specified as a string or a number. =item ttl-lt This field specifies a maximum Time to Live value to match on, i.e., only values less than the one passed as part of this field, will be matched. The value may be specified as a string or a number. =back =head2 unclean match options The C match module matches packets which appear to be ill-formed or otherwise unusual, containing unusual/undefined bits set, invalid flag combinations, and other invalid packet configurations. This match has no option fields. It is still considered experimental. It is known in some older kernels to block packets with ECN bits set. Use it with caution. =head2 DNAT target options The C target allows an incoming connection to be redirected to a specific address, or one of a group of addresses, and one or more ports. The only option to the C target, described below, is required to indicate where a connection is to be redirected to. =over =item to-destination This specifies the redirection address, or addresses, for the C target. The addresses can be specified as a single IP address or a range, or no address with a port specification, or both. (You must have at least one of the above.) One address or address range can be specified as a scalar string, or several can be passed in an array reference (as scalar strings). They should be passed in one of the following forms: ad.d.re.ss ad.d.re.ss-ad.d.re.ss ad.d.re.ss:port ad.d.re.ss:port-port ad.d.re.ss-ad.d.re.ss:port ad.d.re.ss-ad.d.re.ss:port-port :port :port-port =back =head2 DSCP target options This target will allow a rule to apply a Differentiated Services code-point value to the IP headers of outgoing packets. Only one of the following options may be used in any one rule. This target may only be used in the C table. DSCP supplants TOS as a mechanism for indicating the type of service being provided by a packet stream. =over =item set-dscp Specify the numeric Differentiated Services value explicitly. =item set-dscp-class Specify a named Differentiated Services class. This can be one of BE, EF, CS0-CS7, AF11-AF13, AF21-AF23, AF31-AF33, AF41-AF43. =back =head2 FTOS target options The C target sets the Type of Service field in a packet. Unlike the C target, it allows setting an arbitrary value. This value is often used by modern routing hardware to decide how packets should be routed, depending on the needs described by the TOS value. This target is only valid in the C table. The C field, described below, is required when this target is used. =over =item set-ftos This field specifies the Type-of-Service value to be set. The value must be non-negative, and no greater than 255. =back =head2 LOG target options The C target uses the kernel logger (C) to log a message regarding the presence of a packet matching the conditions of the rule. Certain options may be passed to modify the behavior of the C target. =over =item log-level This specifies the logging level, or priority, of the message which the rule should emit when matched. The value can be numeric, or can be a log level name, which is any of C, C, C, C, C (deprecated), C, C, C (a synonym for C, deprecated), or C. =item log-prefix This specifies a prefix string, which will be added to the beginning of the log entry, and can be used as an identifier. =item log-tcp-sequence The presence of this flag indicates that the TCP sequence number of the received packet (if it is a TCP packet) will be appended to the log entry. Note that logging the sequence numbers could be a security hazard. Don't say you weren't warned. The value associated with the key is not checked. =item log-tcp-options The presence of this flag indicates that any TCP option bits specified in the TCP packet header (if it is a TCP packet) will be appended to the log entry. The value associated with the key is not checked. =item log-ip-options The presence of this flag indicates that any IP option bits specified in the IP packet header will be appended to the log entry. The value associated with the key is not checked. =back =head2 MARK target options The C target may be used to set a mark value on a packet. This is commonly used as a way to tag packets for policy-routing later (use iproute2 for this). This target is only valid for use in the C table. =over =item set-mark This option specifies the value to mark the packet with. This field is required for the C target. =back =head2 MASQUERADE target options The C target causes packets to be rewritten before being sent to appear to be destined from the interface they are being routed via. This target is only valid in the C table, in the C chain, or in a user-created chain in the C table (only has an effect if it is linked to from the C chain). =over =item to-ports This option specifies the port or port range to indicate as the packet's source port. If a range is used, the first port in the range will be tried, and if it is unavailable, successive ports will be tried through the last in the range. (If it can't be forwarded because of not having an available port, the packet will be thrown out.) Normally, the MASQUERADE target will try to map to the same port as the packet came from on the originating host whenever possible. =back =head2 MIRROR target options The C target causes a received packet to be directed back to the sending host immediately. This target has no options. It is considered experimental, and generally for testing purposes only. You could really piss some people off with this, so if you choose to use it, use it with caution, and don't say you weren't warned. =head2 REDIRECT target options The C target causes incoming packets to be redirected to the address of the interface they just arrived on. This target is only valid in the C table, in the C chain, or in a user-created chain in the C table (only has an effect if it is linked to from the C chain). =over =item to-ports This option specifies the port or port range to redirect the packet to. If a range is used, the first port in the range will be tried, and if it is unavailable, successive ports will be tried through the last in the range. (If it can't be redirected because of not having an available port, the packet will be thrown out.) Normally, the REDIRECT target will redirect the connection to the same port which it was destined for. =back =head2 REJECT target options The C target allows incoming packets to be rejected, with an appropriate reply packet, instead of just ignoring them (as with the C built-in target). =over =item reject-with This specifies a type of reply to send back as a rejection notice when the rule is matched. The supported types are C (or C for short), C (or C), C (or C), C (or C), C (or C), C (or C), and C (only valid for rules which specifically match TCP packets). =back =head2 SNAT target options The C target allows an incoming connection to be rewritten to appear to be from a different address. This target has only one option, described below, which is required to tell the C target where the connections should be rewritten to appear to be from. =over =item to-source This specifies the rewriting address, or addresses, for the C target. The addresses can be specified as a single IP address or a range, or no address with a port specification, or both. (You must have at least one of the above.) One address or address range can be specified as a scalar string, or several can be passed in an array reference (as scalar strings). The address specification style is as described for the C target's C field, and can be seen above. =back =head2 TCPMSS target options The C target allows limiting of the TCP Maximum Send Size value. This can be particularly useful for firewalls and NAT systems, particularly in cases where the MTU/MSS values differ between the connected networks. Only one of the fields below may be passed. This target is only valid in the C table. It is only allowed for TCP SYN packets. =over =item set-mss This field explicitly specifies the Maximum Send Size value. =item clamp-mss-to-pmtu This field instructs the C target to lock the TCP Maximum Send Size value down to the Path MTU, generally determined via path MTU discovery. The path MTU is a value which indicates the largest packet which can travel unfragmented from source to destination. The TCP packet itself will actually be 40 bytes less than the path MTU value (due to IP and TCP headers). The presence of this field indicates the option is to be enabled. The value format does not matter, as the value will be ignored. =back =head2 TOS target options The C target sets the Type of Service bits in a packet. These bits are often used by modern routing hardware to decide how packets should be routed, depending on the needs described by the TOS bits. This target is only valid in the C table. (Note that TOS is deprecated in preference to DSCP.) =over =item set-tos This field specifies the Type of Service flag which should be set. The Type of Service values include 'Normal-Service' (1), 'Minimize-Cost' (2), 'Maximize-Reliability' (4), 'Maximize-Throughput' (8), and 'Minimize-Delay' (16). Only one of these may be used at a time. The TOS value may be specified as a string or a number, and only these known TOS values will be accepted. This field is required when the C target is used. =back =head2 TTL target options The C target allows the time-to-live value embedded in an IP packet's header to be modified. Only one of the fields specified below may be used per rule. The value should be passed as a non-negative integer, no greater than 255. This target is only valid in the C table. =over =item ttl-set Set the matched packet's TTL value to a specific value. =item ttl-inc Increment the matched packet's TTL value by a specified amount. The amount cannot be zero. =item ttl-dec Decrement the matched packet's TTL value by a specified amount. The amount cannot be zero. If the new TTL value is less than or equal to 0, a 'time-exceeded' reply will be sent back to the originating address. =back =head2 ULOG target options The C target allows flexible, almost universal userspace logging. The C target must be patched into your kernel and you need the ulogd daemon to use the userspace logging. More about C can be found at the site of the C author Harald Welte (F). =over =item ulog-prefix This specifies a prefix string, which will be added to the beginning of the log entry, and can be used as an identifier. =item ulog-nlgroup The netlink multicast group, which ulogd should bind to. =item ulog-copy-range The amount of bytes copied for each packet to the userspace. Has to be in the range 0-1500 (0 means the whole package). =item ulog-qthreshold The amount of packets batched together into one multipart netlink message. This reduces the number of context switches between kernel and userspace. Has to be in the range between 1 and 50. =back =head1 AUTHOR Derrik Pates, dpates@dsdk12.net =head1 SEE ALSO L. =cut