Текст книги "Iptables Tutorial 1.2.2"
Автор книги: Oskar Andreasson
Жанр:
Интернет
сообщить о нарушении
Текущая страница: 12 (всего у книги 30 страниц)
Implicit matches
This section will describe the matches that are loaded implicitly. Implicit matches are implied, taken for granted, automatic. For example when we match on –protocol tcp without any further criteria. There are currently three types of implicit matches for three different protocols. These are TCP matches, UDP matches and ICMP matches. The TCP based matches contain a set of unique criteria that are available only for TCP packets. UDP based matches contain another set of criteria that are available only for UDP packets. And the same thing for ICMP packets. On the other hand, there can be explicit matches that are loaded explicitly. Explicit matches are not implied or automatic, you have to specify them specifically. For these you use the -m or –match option, which we will discuss in the next section.
TCP matches
These matches are protocol specific and are only available when working with TCP packets and streams. To use these matches, you need to specify –protocol tcp on the command line before trying to use them. Note that the –protocol tcp match must be to the left of the protocol specific matches. These matches are loaded implicitly in a sense, just as the UDP and ICMP matches are loaded implicitly. The other matches will be looked over in the continuation of this section, after the TCP match section.
Table 10-2. TCP matches
| Match | –sport, –source-port |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp –sport 22 |
| Explanation | The –source-port match is used to match packets based on their source port. Without it, we imply all source ports. This match can either take a service name or a port number. If you specify a service name, the service name must be in the /etc/services file, since iptables uses this file in which to find. If you specify the port by its number, the rule will load slightly faster, since iptables don't have to check up the service name. However, the match might be a little bit harder to read than if you use the service name. If you are writing a rule-set consisting of a 200 rules or more, you should definitely use port numbers, since the difference is really noticeable. (On a slow box, this could make as much as 10 seconds' difference, if you have configured a large rule-set containing 1000 rules or so). You can also use the –source-port match to match any range of ports, –source-port 22:80 for example. This example would match all source ports between 22 and 80. If you omit specifying the first port, port 0 is assumed (is implicit). –source-port :80 would then match port 0 through 80. And if the last port specification is omitted, port 65535 is assumed. If you were to write –source-port 22:, you would have specified a match for all ports from port 22 through port 65535. If you invert the port range, iptables automatically reverses your inversion. If you write –source-port 80:22, it is simply interpreted as –source-port 22:80. You can also invert a match by adding a ! sign. For example, –source-port ! 22 means that you want to match all ports but port 22. The inversion could also be used together with a port range and would then look like –source-port ! 22:80, which in turn would mean that you want to match all ports but ports 22 through 80. Note that this match does not handle multiple separated ports and port ranges. For more information about those, look at the multiport match extension. |
| Match | –dport, –destination-port |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp –dport 22 |
| Explanation | This match is used to match TCP packets, according to their destination port. It uses exactly the same syntax as the –source-port match. It understands port and port range specifications, as well as inversions. It also reverses high and low ports in port range specifications, as above. The match will also assume values of 0 and 65535 if the high or low port is left out in a port range specification. In other words, exactly the same as the –source-port syntax. Note that this match does not handle multiple separated ports and port ranges. For more information about those, look at the multiport match extension. |
| Match | –tcp-flags |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -p tcp –tcp-flags SYN,FIN,ACK SYN |
| Explanation | This match is used to match on the TCP flags in a packet. First of all, the match takes a list of flags to compare (a mask) and secondly it takes list of flags that should be set to 1, or turned on. Both lists should be comma-delimited. The match knows about the SYN, ACK, FIN, RST, URG, PSH flags, and it also recognizes the words ALL and NONE. ALL and NONE is pretty much self describing: ALL means to use all flags and NONE means to use no flags for the option. –tcp-flags ALL NONE would in other words mean to check all of the TCP flags and match if none of the flags are set. This option can also be inverted with the ! sign. For example, if we specify ! SYN,FIN,ACK SYN, we would get a match that would match packets that had the ACK and FIN bits set, but not the SYN bit. Also note that the comma delimitation should not include spaces. You can see the correct syntax in the example above. |
| Match | –syn |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -p tcp –syn |
| Explanation | The –syn match is more or less an old relic from the ipchains days and is still there for backward compatibility and for and to make transition one to the other easier. It is used to match packets if they have the SYN bit set and the ACK and RST bits unset. This command would in other words be exactly the same as the –tcp-flags SYN,RST,ACK SYN match. Such packets are mainly used to request new TCP connections from a server. If you block these packets, you should have effectively blocked all incoming connection attempts. However, you will not have blocked the outgoing connections, which a lot of exploits today use (for example, hacking a legitimate service and then installing a program or suchlike that enables initiating an existing connection to your host, instead of opening up a new port on it). This match can also be inverted with the ! sign in this, ! –syn, way. This would match all packets with the RST or the ACK bits set, in other words packets in an already established connection. |
| Match | –tcp-option |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -p tcp –tcp-option 16 |
| Explanation | This match is used to match packets depending on their TCP options. A TCP Option is a specific part of the header. This part consists of 3 different fields. The first one is 8 bits long and tells us which Options are used in this stream, the second one is also 8 bits long and tells us how long the options field is. The reason for this length field is that TCP options are, well, optional. To be compliant with the standards, we do not need to implement all options, but instead we can just look at what kind of option it is, and if we do not support it, we just look at the length field and can then jump over this data. This match is used to match different TCP options depending on their decimal values. It may also be inverted with the ! flag, so that the match matches all TCP options but the option given to the match. For a complete list of all options, take a closer look at the Internet Engineering Task Force who maintains a list of all the standard numbers used on the Internet. |
UDP matches
This section describes matches that will only work together with UDP packets. These matches are implicitly loaded when you specify the –protocol UDP match and will be available after this specification. Note that UDP packets are not connection oriented, and hence there is no such thing as different flags to set in the packet to give data on what the datagram is supposed to do, such as open or closing a connection, or if they are just simply supposed to send data. UDP packets do not require any kind of acknowledgment either. If they are lost, they are simply lost (Not taking ICMP error messaging etc into account). This means that there are quite a lot less matches to work with on a UDP packet than there is on TCP packets. Note that the state machine will work on all kinds of packets even though UDP or ICMP packets are counted as connectionless protocols. The state machine works pretty much the same on UDP packets as on TCP packets.
Table 10-3. UDP matches
| Match | –sport, –source-port |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p udp –sport 53 |
| Explanation | This match works exactly the same as its TCP counterpart. It is used to perform matches on packets based on their source UDP ports. It has support for port ranges, single ports and port inversions with the same syntax. To specify a UDP port range, you could use 22:80 which would match UDP ports 22 through 80. If the first value is omitted, port 0 is assumed. If the last port is omitted, port 65535 is assumed. If the high port comes before the low port, the ports switch place with each other automatically. Single UDP port matches look as in the example above. To invert the port match, add a ! sign, –source-port ! 53. This would match all ports but port 53. The match can understand service names, as long as they are available in the /etc/services file. Note that this match does not handle multiple separated ports and port ranges. For more information about this, look at the multiport match extension. |
| Match | –dport, –destination-port |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p udp –dport 53 |
| Explanation | The same goes for this match as for –source-port above. It is exactly the same as for the equivalent TCP match, but here it applies to UDP packets. It matches packets based on their UDP destination port. The match handles port ranges, single ports and inversions. To match a single port you use, for example, –destination-port 53, to invert this you would use –destination-port ! 53. The first would match all UDP packets going to port 53 while the second would match packets but those going to the destination port 53. To specify a port range, you would, for example, use –destination-port 9:19. This example would match all packets destined for UDP port 9 through 19. If the first port is omitted, port 0 is assumed. If the second port is omitted, port 65535 is assumed. If the high port is placed before the low port, they automatically switch place, so the low port winds up before the high port. Note that this match does not handle multiple ports and port ranges. For more information about this, look at the multiport match extension. |
ICMP matches
These are the ICMP matches. These packets are even more ephemeral, that is to say short lived, than UDP packets, in the sense that they are connectionless. The ICMP protocol is mainly used for error reporting and for connection controlling and suchlike. ICMP is not a protocol subordinated to the IP protocol, but more of a protocol that augments the IP protocol and helps in handling errors. The headers of ICMP packets are very similar to those of the IP headers, but differ in a number of ways. The main feature of this protocol is the type header, that tells us what the packet is for. One example is, if we try to access an unaccessible IP address, we would normally get an ICMP host unreachable in return. For a complete listing of ICMP types, see the ICMP types appendix. There is only one ICMP specific match available for ICMP packets, and hopefully this should suffice. This match is implicitly loaded when we use the –protocol ICMP match and we get access to it automatically. Note that all the generic matches can also be used, so that among other things we can match on the source and destination addresses.
Table 10-4. ICMP matches
| Match | –icmp-type |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p icmp –icmp-type 8 |
| Explanation | This match is used to specify the ICMP type to match. ICMP types can be specified either by their numeric values or by their names. Numerical values are specified in RFC 792. To find a complete listing of the ICMP name values, do an iptables –protocol icmp –help, or check the ICMP types appendix. This match can also be inverted with the ! sign in this, –icmp-type ! 8, fashion. Note that some ICMP types are obsolete, and others again may be "dangerous" for an unprotected host since they may, among other things, redirect packets to the wrong places. The type and code may also be specified by their typename, numeric type, and type/code as well. For example –icmp-type network-redirect, –icmp-type 8 or –icmp-type 8/0. For a complete listing of the names, type iptables -p icmp –help. |
SCTP matches
SCTP or Stream Control Transmission Protocol is a relatively new occurence in the networking domain in comparison to the TCP and UDP protocols. The SCTP Characteristics chapter explains the protocol more in detail. The implicit SCTP matches are loaded through adding the -p sctp match to the command line of iptables.
The SCTP protocol was developed by some of the larger telecom and switch/network manufacturers out there, and the protocol is specifically well suited for large simultaneous transactions with high reliability and high throughput.
Table 10-5. SCTP matches
| Match | –source-port, –sport |
| Kernel | 2.6 |
| Example | iptables -A INPUT -p sctp –source-port 80 |
| Explanation | The –source-port match is used to match an SCTP packet based on the source port in the SCTP packet header. The port can either be a single port, as in the example above, or a range of ports specified as –source-port 20:100, or it can also be inverted with the !-sign. This looks, for example, like –source-port ! 25. The source port is an unsigned 16 bit integer, so the maximum value is 65535 and the lowest value is 0. |
| Match | –destination-port, –dport |
| Kernel | 2.6 |
| Example | iptables -A INPUT -p sctp –destination-port 80 |
| Explanation | This match is used for the destination port of the SCTP packets. All SCTP packets contain a destination port, just as it does a source port, in the headers. The port can be either specified as in the example above, or with a port range such as –destination-port 6660:6670. The command can also be inverted with the !-sign, for example, –destination-port ! 80. This example would match all packets but those to port 80. The same applies for destination ports as for source ports, the highest port is 65535 and the lowest is 0. |
| Match | –chunk-types |
| Kernel | 2.6 |
| Example | iptables -A INPUT -p sctp –chunk-types any INIT,INIT_ACK |
| Explanation | This matches the chunk type of the SCTP packet. Currently there are a host of different chunk types available. For a complete list, see below. The match begins with the –chunk-types keyword, and then continues with a flag noting if we are to match all, any or none. After this, you specify the SCTP Chunk Types to match for. The Chunk Types are available in the separate list below. |
| Additionally, the flags can take some Chunk Flags as well. This is done for example in the form –chunk-types any DATA:Be. The flags are specific for each SCTP Chunk type and must be valid according to the separate list after this table. | |
| If an upper case letter is used, the flag must be set, and if a lower case flag is set it must be unset to match. The whole match can be inversed by using an ! sign just after the –chunk-types keyword. For example, –chunk-types ! any DATA:Be would match anything but this pattern. |
Below is the list of chunk types that the –chunk-types match will recognize. The list is quite extensive as you can see, but the mostly used packets are DATA and SACK packets. The rest are mostly used for controlling the association.
SCTP Chunk types as used in –chunk-types
• ABORT
• ASCONF
• ASCONF_ACK
• COOKIE_ACK
• COOKIE_ECHO
• DATA
• ECN_CWR
• ECN_ECNE
• ERROR
• HEARTBEAT
• HEARTBEAT_ACK
• INIT
• INIT_ACK
• SACK
• SHUTDOWN
• SHUTDOWN_ACK
• SHUTDOWN_COMPLETE
The following flags can be used with the –chunk-types match as seen above. According to the RFC 2960 – Stream Control Transmission Protocol all the rest of the flags are reserved or not in use, and must be set to 0. Iptables does currently not contain any measures to enforce this, fortunately, since it begs to become another problem such as the one previously experienced when ECN was implemented in the IP protocol.
SCTP Chunk flags as used in –chunk-types
• DATA – U or u for Unordered bit, B or b for Beginning fragment bit and E or e for Ending fragment bit.
• ABORT – T or t for TCB destroy flag.
• SHUTDOWN_COMPLETE – T or t for TCB destroyed flag.
Explicit matches
Explicit matches are those that have to be specifically loaded with the -m or –match option. State matches, for example, demand the directive -m state prior to entering the actual match that you want to use. Some of these matches may be protocol specific . Some may be unconnected with any specific protocol – for example connection states. These might be NEW (the first packet of an as yet unestablished connection), ESTABLISHED (a connection that is already registered in the kernel), RELATED (a new connection that was created by an older, established one) etc. A few may just have been evolved for testing or experimental purposes, or just to illustrate what iptables is capable of. This in turn means that not all of these matches may at first sight be of any use. Nevertheless, it may well be that you personally will find a use for specific explicit matches. And there are new ones coming along all the time, with each new iptables release. Whether you find a use for them or not depends on your imagination and your needs. The difference between implicitly loaded matches and explicitly loaded ones, is that the implicitly loaded matches will automatically be loaded when, for example, you match on the properties of TCP packets, while explicitly loaded matches will never be loaded automatically – it is up to you to discover and activate explicit matches.
Addrtype match
The addrtype module matches packets based on the address type. The address type is used inside the kernel to put different packets into different categories. With this match you will be able to match all packets based on their address type according to the kernel. It should be noted that the exact meaning of the different address types varies between the layer 3 protocols. I will give a brief general description here however, but for more information I suggest reading Linux Advanced Routing and Traffic Control HOW-TO and Policy Routing using Linux. The available types are as follows:
Table 10-6. Address types
| Type | Description |
|---|---|
| ANYCAST | This is a one-to-many associative connection type, where only one of the many receiver hosts actually receives the data. This is for example implemented in DNS. You have single address to a root server, but it actually has several locations and your packet will be directed to the closest working server. Not implemented in Linux IPv4. |
| BLACKHOLE | A blackhole address will simply delete the packet and send no reply. It works as a black hole in space basically. This is configured in the routing tables of linux. |
| BROADCAST | A broadcast packet is a single packet sent to everyone in a specific network in a one-to-many relation. This is for example used in ARP resolution, where a single packet is sent out requesting information on how to reach a specific IP, and then the host that is authoritative replies with the proper MAC address of that host. |
| LOCAL | An address that is local to the host we are working on. 127.0.0.1 for example. |
| MULTICAST | A multicast packet is sent to several hosts using the shortest distance and only one packet is sent to each waypoint where it will be multiple copies for each host/router subscribing to the specific multicast address. Commonly used in one way streaming media such as video or sound. |
| NAT | An address that has been NAT'ed by the kernel. |
| PROHIBIT | Same as blackhole except that a prohibited answer will be generated. In the IPv4 case, this means an ICMP communication prohibited (type 3, code 13) answer will be generated. |
| THROW | Special route in the Linux kernel. If a packet is thrown in a routing table it will behave as if no route was found in the table. In normal routing, this means that the packet will behave as if it had no route. In policy routing, another route might be found in another routing table. |
| UNICAST | A real routable address for a single address. The most common type of route. |
| UNREACHABLE | This signals an unreachable address that we do not know how to reach. The packets will be discarded and an ICMP Host unreachable (type 3, code 1) will be generated. |
| UNSPEC | An unspecified address that has no real meaning. |
| XRESOLVE | This address type is used to send route lookups to userland applications which will do the lookup for the kernel. This might be wanted to send ugly lookups to the outside of the kernel, or to have an application do lookups for you. Not implemented in Linux. |
The addrtype match is loaded by using the -m addrtype keyword. When this is done, the extra match options in the following table will be available for usage.
Table 10-7. Addrtype match options
| Match | –src-type |
| Kernel | 2.6 |
| Example | iptables -A INPUT -m addrtype –src-type UNICAST |
| Explanation | The –src-type match option is used to match the source address type of the packet. It can either take a single address type or several separated by coma signs, for example –src-type BROADCAST,MULTICAST. The match option may also be inverted by adding an exclamation sign before it, for example ! –src-type BROADCAST,MULTICAST. |
| Match | –dst-type |
| Kernel | 2.6 |
| Example | iptables -A INPUT -m addrtype –dst-type UNICAST |
| Explanation | The –dst-type works exactly the same way as –src-type and has the same syntax. The only difference is that it will match packets based on their destination address type. |
