Текст книги "Iptables Tutorial 1.2.2"
Автор книги: Oskar Andreasson
Жанр:
Интернет
сообщить о нарушении
Текущая страница: 13 (всего у книги 30 страниц)
These matches are used for the IPSEC AH and ESP protocols. IPSEC is used to create secure tunnels over an insecure Internet connection. The AH and ESP protocols are used by IPSEC to create these secure connections. The AH and ESP matches are really two separate matches, but are both described here since they look very much alike, and both are used in the same function.
I will not go into detail to describe IPSEC here, instead look at the following pages and documents for more information:
• RFC 2401 – Security Architecture for the Internet Protocol
• FreeS/WAN
• IPSEC Howto
• Linux Advanced Routing and Traffic Control HOW-TO
There is also a ton more documentation on the Internet on this, but you are free to look it up as needed.
To use the AH/ESP matches, you need to use -m ah to load the AH matches, and -m esp to load the ESP matches.
Note In 2.2 and 2.4 kernels, Linux used something called FreeS/WAN for the IPSEC implementation, but as of Linux kernel 2.5.47 and up, Linux kernels have a direct implementation of IPSEC that requires no patching of the kernel. This is a total rewrite of the IPSEC implementation on Linux.
Table 10-8. AH match options
| Match | –ahspi |
| Kernel | 2.5 and 2.6 |
| Example | iptables -A INPUT -p 51 -m ah –ahspi 500 |
| Explanation | This matches the AH Security Parameter Index (SPI) number of the AH packets. Please note that you must specify the protocol as well, since AH runs on a different protocol than the standard TCP, UDP or ICMP protocols. The SPI number is used in conjunction with the source and destination address and the secret keys to create a security association (SA). The SA uniquely identifies each and every one of the IPSEC tunnels to all hosts. The SPI is used to uniquely distinguish each IPSEC tunnel connected between the same two peers. Using the –ahspi match, we can match a packet based on the SPI of the packets. This match can match a whole range of SPI values by using a : sign, such as 500:520, which will match the whole range of SPI's. |
Table 10-9. ESP match options
| Match | –espspi |
| Kernel | 2.5 and 2.6 |
| Example | iptables -A INPUT -p 50 -m esp –espspi 500 |
| Explanation | The ESP counterpart Security Parameter Index (SPI) is used exactly the same way as the AH variant. The match looks exactly the same, with the esp/ah difference. Of course, this match can match a whole range of SPI numbers as well as the AH variant of the SPI match, such as –espspi 200:250 which matches the whole range of SPI's. |
Comment match
The comment match is used to add comments inside the iptables ruleset and the kernel. This can make it much easier to understand your ruleset and to ease debugging. For example, you could add comments documenting which bash function added specific sets of rules to netfilter, and why. It should be noted that this isn't actually a match. The comment match is loaded using the -m comment keywords. At this point the following options will be available.
Table 10-10. Comment match options
| Match | –comment |
| Kernel | 2.6 |
| Example | iptables -A INPUT -m comment –comment "A comment" |
| Explanation | The –comment option specifies the comment to actually add to the rule in kernel. The comment can be a maximum of 256 characters. |
Connmark match
The connmark match is used very much the same way as the mark match is in the MARK/mark target and match combination. The connmark match is used to match marks that has been set on a connection with the CONNMARK target. It only takes one option.
Important To match a mark on the same packet as is the first to create the connection marking, you must use the connmark match after the CONNMARK target has set the mark on the first packet.
Table 10-11. Connmark match options
| Match | –mark |
| Kernel | 2.6 |
| Example | iptables -A INPUT -m connmark –mark 12 -j ACCEPT |
| Explanation | The mark option is used to match a specific mark associated with a connection. The mark match must be exact, and if you want to filter out unwanted flags from the connection mark before actually matching anything, you can specify a mask that will be anded to the connection mark. For example, if you have a connection mark set to 33 (10001 in binary) on a connection, and want to match the first bit only, you would be able to run something like –mark 1/1. The mask (00001) would be masked to 10001, so 10001 && 00001 equals 1, and then matched against the 1. |
Conntrack match
The conntrack match is an extended version of the state match, which makes it possible to match packets in a much more granular way. It let's you look at information directly available in the connection tracking system, without any "frontend" systems, such as in the state match. For more information about the connection tracking system, take a look at the The state machine chapter.
There are a number of different matches put together in the conntrack match, for several different fields in the connection tracking system. These are compiled together into the list below. To load these matches, you need to specify -m conntrack.
Table 10-12. Conntrack match options
| Match | –ctstate |
| Kernel | 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m conntrack –ctstate RELATED |
| Explanation | This match is used to match the state of a packet, according to the conntrack state. It is used to match pretty much the same states as in the original state match. The valid entries for this match are: |
| • INVALID | |
| • ESTABLISHED | |
| • NEW | |
| • RELATED | |
| • SNAT | |
| • DNAT | |
| The entries can be used together with each other separated by a comma. For example, -m conntrack –ctstate ESTABLISHED,RELATED. It can also be inverted by putting a ! in front of –ctstate. For example: -m conntrack ! –ctstate ESTABLISHED,RELATED, which matches all but the ESTABLISHED and RELATED states. | |
| Match | –ctproto |
| Kernel | 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m conntrack –ctproto TCP |
| Explanation | This matches the protocol, the same as the –protocol does. It can take the same types of values, and is inverted using the ! sign. For example, -m conntrack ! –ctproto TCP matches all protocols but the TCP protocol. |
| Match | –ctorigsrc |
| Kernel | 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m conntrack –ctorigsrc 192.168.0.0/24 |
| Explanation | –ctorigsrc matches based on the original source IP specification of the conntrack entry that the packet is related to. The match can be inverted by using a ! between the –ctorigsrc and IP specification, such as –ctorigsrc ! 192.168.0.1. It can also take a netmask of the CIDR form, such as –ctorigsrc 192.168.0.0/24. |
| Match | –ctorigdst |
| Kernel | 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m conntrack –ctorigdst 192.168.0.0/24 |
| Explanation | This match is used exactly as the –ctorigsrc, except that it matches on the destination field of the conntrack entry. It has the same syntax in all other respects. |
| Match | –ctreplsrc |
| Kernel | 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m conntrack –ctreplsrc 192.168.0.0/24 |
| Explanation | The –ctreplsrc match is used to match based on the original conntrack reply source of the packet. Basically, this is the same as the –ctorigsrc, but instead we match the reply source expected of the upcoming packets. This target can, of course, be inverted and address a whole range of addresses, just the same as the the previous targets in this class. |
| Match | –ctrepldst |
| Kernel | 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m conntrack –ctrepldst 192.168.0.0/24 |
| Explanation | The –ctrepldst match is the same as the –ctreplsrc match, with the exception that it matches the reply destination of the conntrack entry that matched the packet. It too can be inverted, and accept ranges, just as the –ctreplsrc match. |
| Match | –ctstatus |
| Kernel | 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m conntrack –ctstatus RELATED |
| Explanation | This matches the status of the connection, as described in the The state machine chapter. It can match the following statuses. |
| • NONE – The connection has no status at all. | |
| • EXPECTED – This connection is expected and was added by one of the expectation handlers. | |
| • SEEN_REPLY – This connection has seen a reply but isn't assured yet. | |
| • ASSURED – The connection is assured and will not be removed until it times out or the connection is closed by either end. | |
| This can also be inverted by using the ! sign. For example -m conntrack ! –ctstatus ASSURED which will match all but the ASSURED status. | |
| Match | –ctexpire |
| Kernel | 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m conntrack –ctexpire 100:150 |
| Explanation | This match is used to match on packets based on how long is left on the expiration timer of the conntrack entry, measured in seconds. It can either take a single value and match against, or a range such as in the example above. It can also be inverted by using the ! sign, such as this -m conntrack ! –ctexpire 100. This will match every expiration time, which does not have exactly 100 seconds left to it. |
Dscp match
This match is used to match on packets based on their DSCP (Differentiated Services Code Point) field. This is documented in the RFC 2638 – A Two-bit Differentiated Services Architecture for the Internet RFC. The match is explicitly loaded by specifying -m dscp. The match can take two mutually exclusive options, described below.
Table 10-13. Dscp match options
| Match | –dscp |
| Kernel | 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m dscp –dscp 32 |
| Explanation | This option takes a DSCP value in either decimal or in hex. If the option value is in decimal, it would be written like 32 or 16, et cetera. If written in hex, it should be prefixed with 0x, like this: 0x20. It can also be inverted by using the ! character, like this: -m dscp ! –dscp 32. |
| Match | –dscp-class |
| Kernel | 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m dscp –dscp-class BE |
| Explanation | The –dscp-class match is used to match on the DiffServ class of a packet. The values can be any of the BE, EF, AFxx or CSx classes as specified in the various RFC's. This match can be inverted just the same way as the –dscp option. |
Note Please note that the –dscp and –dscp-class options are mutually exclusive and can not be used in conjunction with each other.
Ecn matchThe ecn match is used to match on the different ECN fields in the TCP and IPv4 headers. ECN is described in detail in the RFC 3168 – The Addition of Explicit Congestion Notification (ECN) to IP RFC. The match is explicitly loaded by using -m ecn in the command line. The ecn match takes three different options as described below.
Table 10-14. Ecn match options
| Match | –ecn |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m ecn –ecn-tcp-cwr |
| Explanation | This match is used to match the CWR (Congestion Window Received) bit, if it has been set. The CWR flag is set to notify the other endpoint of the connection that they have received an ECE, and that they have reacted to it. Per default this matches if the CWR bit is set, but the match may also be inversed using an exclamation point. |
| Match | –ecn-tcp-ece |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m ecn –ecn-tcp-ece |
| Explanation | This match can be used to match the ECE (ECN-Echo) bit. The ECE is set once one of the endpoints has received a packet with the CE bit set by a router. The endpoint then sets the ECE in the returning ACK packet, to notify the other endpoint that it needs to slow down. The other endpoint then sends a CWR packet as described in the –ecn-tcp-cwr explanation. This matches per default if the ECE bit is set, but may be inversed by using an exclamation point. |
| Match | –ecn-ip-ect |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m ecn –ecn-ip-ect 1 |
| Explanation | The –ecn-ip-ect match is used to match the ECT (ECN Capable Transport) codepoints. The ECT codepoints has several types of usage. Mainly, they are used to negotiate if the connection is ECN capable by setting one of the two bits to 1. The ECT is also used by routers to indicate that they are experiencing congestion, by setting both ECT codepoints to 1. The ECT values are all available in the in the ECN Field in IP table below. |
| The match can be inversed using an exclamation point, for example ! –ecn-ip-ect 2 which will match all ECN values but the ECT(0) codepoint. The valid value range is 0-3 in iptables. See the above table for their values. |
Table 10-15. ECN Field in IP
| Iptables value | ECT | CE | [Obsolete] RFC 2481 names for the ECN bits. |
|---|---|---|---|
| Not-ECT, ie. non-ECN capable connection. | |||
| 1 | 1 | ECT(1), New naming convention of ECT codepoints in RFC 3168. | |
| 2 | 1 | ECT(0), New naming convention of ECT codepoints in RFC 3168. | |
| 3 | 1 | 1 | CE (Congestion Experienced), Used to notify endpoints of congestion |
Hashlimit match
This is a modified version of the Limit match. Instead of just setting up a single token bucket, it sets up a hash table pointing to token buckets for each destination IP, source IP, destination port and source port tuple. For example, you can set it up so that every IP address can receive a maximum of 1000 packets per second, or you can say that every service on a specific IP address may receive a maximum of 200 packets per second. The hashlimit match is loaded by specifying the -m hashlimit keywords.
Each rule that uses the hashlimit match creates a separate hashtable which in turn has a specific max size and a maximum number of buckets. This hash table contains a hash of either a single or multiple values. The values can be any and/or all of destination IP, source IP, destination port and source port. Each entry then points to a token bucket that works as the limit match.
Table 10-16. Hashlimit match options
| Match | –hashlimit |
| Kernel | 2.6 |
| Example | iptables -A INPUT -p tcp –dst 192.168.0.3 -m hashlimit –hashlimit 1000/sec –hashlimit-mode dstip,dstport –hashlimit-name hosts |
| Explanation | The –hashlimit specifies the limit of each bucket. In this example the hashlimit is set to 1000. In this example, we have set up the hashlimit-mode to be dstip,dstport and destination 192.168.0.3. Hence, for every port or service on the destination host, it can receive 1000 packets per second. This is the same setting as the limit option for the limit match. The limit can take a /sec, /minute, /hour or /day postfix. If no postfix is specified, the default postfix is per second. |
| Match | –hashlimit-mode |
| Kernel | 2.6 |
| Example | iptables -A INPUT -p tcp –dst 192.168.0.0/16 -m hashlimit –hashlimit 1000/sec –hashlimit-mode dstip –hashlimit-name hosts |
| Explanation | The –hashlimit-mode option specifies which values we should use as the hash values. In this example, we use only the dstip (destination IP) as the hashvalue. So, each host in the 192.168.0.0/16 network will be limited to receiving a maximum of 1000 packets per second in this case. The possible values for the –hashlimit-mode is dstip (Destination IP), srcip (Source IP), dstport (Destination port) and srcport (Source port). All of these can also be separated by a comma sign to include more than one hashvalue, such as for example –hashlimit-mode dstip,dstport. |
| Match | –hashlimit-name |
| Kernel | 2.6 |
| Example | iptables -A INPUT -p tcp –dst 192.168.0.3 -m hashlimit –hashlimit 1000 –hashlimit-mode dstip,dstport –hashlimit-name hosts |
| Explanation | This option specifies the name that this specific hash will be available as. It can be viewed inside the /proc/net/ipt_hashlimit directory. The example above would be viewable inside the /proc/net/ipt_hashlimit/hosts file. Only the filename should be specified. |
| Match | –hashlimit-burst |
| Kernel | 2.6 |
| Example | iptables -A INPUT -p tcp –dst 192.168.0.3 -m hashlimit –hashlimit 1000 –hashlimit-mode dstip,dstport –hashlimit-name hosts –hashlimit-burst 2000 |
| Explanation | This match is the same as the –limit-burst in that it sets the maximum size of the bucket. Each bucket will have a burst limit, which is the maximum amount of packets that can be matched during a single time unit. For an example on how a token bucket works, take a look at the Limit match. |
| Match | –hashlimit-htable-size |
| Kernel | 2.6 |
| Example | iptables -A INPUT -p tcp –dst 192.168.0.3 -m hashlimit –hashlimit 1000 –hashlimit-mode dstip,dstport –hashlimit-name hosts –hashlimit-htable-size 500 |
| Explanation | This sets the maximum available buckets to be used. In this example, it means that a maximum of 500 ports can be open and active at the same time. |
| Match | –hashlimit-htable-max |
| Kernel | 2.6 |
| Example | iptables -A INPUT -p tcp –dst 192.168.0.3 -m hashlimit –hashlimit 1000 –hashlimit-mode dstip,dstport –hashlimit-name hosts –hashlimit-htable-max 500 |
| Explanation | The –hashlimit-htable-max sets the maximum number of hashtable entries. This means all of the connections, including the inactive connections that doesn't require any token buckets for the moment. |
| Match | –hashlimit-htable-gcinterval |
| Kernel | 2.6 |
| Example | iptables -A INPUT -p tcp –dst 192.168.0.3 -m hashlimit –hashlimit 1000 –hashlimit-mode dstip,dstport –hashlimit-name hosts –hashlimit-htable-gcinterval 1000 |
| Explanation | How often should the garbage collection function be run. Generally speaking this value should be lower than the expire value. The value is measured in milliseconds. If it is set too low it will be taking up unnecessary system resources and processing power, but if it's too high it can leave unused token buckets lying around for too long and leaving other connections impossible. In this example the garbage collector will run every second. |
| Match | –hashlimit-htable-expire |
| Kernel | 2.6 |
| Example | iptables -A INPUT -p tcp –dst 192.168.0.3 -m hashlimit –hashlimit 1000 –hashlimit-mode dstip,dstport –hashlimit-name hosts –hashlimit-htable-expire 10000 |
| Explanation | This value sets after how long time an idle hashtable entry should expire. If a bucket has been unused for longer than this, it will be expired and the next garbage collection run will remove it from the hashtable, as well as all of the information pertaining to it. |
Helper match
This is a rather unorthodox match in comparison to the other matches, in the sense that it uses a little bit specific syntax. The match is used to match packets, based on which conntrack helper that the packet is related to. For example, let's look at the FTP session. The Control session is opened up, and the ports/connection is negotiated for the Data session within the Control session. The ip_conntrack_ftp helper module will find this information, and create a related entry in the conntrack table. Now, when a packet enters, we can see which protocol it was related to, and we can match the packet in our ruleset based on which helper was used. The match is loaded by using the -m helper keyword.
Table 10-17. Helper match options
| Match | –helper |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m helper –helper ftp-21 |
| Explanation | The –helper option is used to specify a string value, telling the match which conntrack helper to match. In the basic form, it may look like –helper irc. This is where the syntax starts to change from the normal syntax. We can also choose to only match packets based on which port that the original expectation was caught on. For example, the FTP Control session is normally transferred over port 21, but it may as well be port 954 or any other port. We may then specify upon which port the expectation should be caught on, like –helper ftp-954. |
IP range match
The IP range match is used to match IP ranges, just as the –source and –destination matches are able to do as well. However, this match adds a different kind of matching in the sense that it is able to match in the manner of from IP – to IP, which the –source and –destination matches are unable to. This may be needed in some specific network setups, and it is rather a bit more flexible. The IP range match is loaded by using the -m iprange keyword.
Table 10-18. IP range match options
| Match | –src-range |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m iprange –src-range 192.168.1.13-192.168.2.19 |
| Explanation | This matches a range of source IP addresses. The range includes every single IP address from the first to the last, so the example above includes everything from 192.168.1.13 to 192.168.2.19. The match may also be inverted by adding an !. The above example would then look like -m iprange ! –src-range 192.168.1.13-192.168.2.19, which would match every single IP address, except the ones specified. |
| Match | –dst-range |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m iprange –dst-range 192.168.1.13-192.168.2.19 |
| Explanation | The –dst-range works exactly the same as the –src-range match, except that it matches destination IP's instead of source IP's. |
