Текст книги "Iptables Tutorial 1.2.2"
Автор книги: Oskar Andreasson
Жанр:
Интернет
сообщить о нарушении
Текущая страница: 14 (всего у книги 30 страниц)
The length match is used to match packets based on their length. It is very simple. If you want to limit packet length for some strange reason, or want to block ping-of-death-like behaviour, use the length match.
Table 10-19. Length match options
| Match | –length |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m length –length 1400:1500 |
| Explanation | The example –length will match all packets with a length between 1400 and 1500 bytes. The match may also be inversed using the ! sign, like this: -m length ! –length 1400:1500 . It may also be used to match only a specific length, removing the : sign and onwards, like this: -m length –length 1400. The range matching is, of course, inclusive, which means that it includes all packet lengths in between the values you specify. |
Limit match
The limit match extension must be loaded explicitly with the -m limit option. This match can, for example, be used to advantage to give limited logging of specific rules etc. For example, you could use this to match all packets that do not exceed a given value, and after this value has been exceeded, limit logging of the event in question. Think of a time limit: You could limit how many times a certain rule may be matched in a certain time frame, for example to lessen the effects of DoS syn flood attacks. This is its main usage, but there are more usages, of course. The limit match may also be inverted by adding a ! flag in front of the limit match. It would then be expressed as -m limit ! –limit 5/s.This means that all packets will be matched after they have broken the limit.
To further explain the limit match, it is basically a token bucket filter. Consider having a leaky bucket where the bucket leaks X packets per time-unit. X is defined depending on how many matching packets we get, so if we get 3 packets, the bucket leaks 3 packets per that time-unit. The –limit option tells us how many packets to refill the bucket with per time-unit, while the –limit-burst option tells us how big the bucket is in the first place. So, setting –limit 3/minute –limit-burst 5, and then receiving 5 matches will empty the bucket. After 20 seconds, the bucket is refilled with another token, and so on until the –limit-burst is reached again or until they get used.
Consider the example below for further explanation of how this may look.
We set a rule with -m limit –limit 5/second –limit-burst 10/second. The limit-burst token bucket is set to 10 initially. Each packet that matches the rule uses a token.
We get packet that matches, 1-2-3-4-5-6-7-8-9-10, all within a 1/1000 of a second.
The token bucket is now empty. Once the token bucket is empty, the packets that qualify for the rule otherwise no longer match the rule and proceed to the next rule if any, or hit the chain policy.
For each 1/5 s without a matching packet, the token count goes up by 1, upto a maximum of 10. 1 second after receiving the 10 packets, we will once again have 5 tokens left.
And of course, the bucket will be emptied by 1 token for each packet it receives.
Table 10-20. Limit match options
| Match | –limit |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -m limit –limit 3/hour |
| Explanation | This sets the maximum average match rate for the limit match. You specify it with a number and an optional time unit. The following time units are currently recognized: /second /minute /hour /day. The default value here is 3 per hour, or 3/hour. This tells the limit match how many times to allow the match to occur per time unit (e.g. per minute). |
| Match | –limit-burst |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -m limit –limit-burst 5 |
| Explanation | This is the setting for the burst limit of the limit match. It tells iptables the maximum number of tokens available in the bucket when we start, or when the bucket is full. This number gets decremented by one for every packet that arrives, down to the lowest possible value, 1. The bucket will be refilled by the limit value every time unit, as specified by the –limit option. The default –limit-burst value is 5. For a simple way of checking out how this works, you can use the example Limit-match.txt one-rule-script. Using this script, you can see for yourself how the limit rule works, by simply sending ping packets at different intervals and in different burst numbers. All echo replies will be blocked when the burst value has been exceeded, and then be refilled by the limit value every second. |
Mac match
The MAC (Ethernet Media Access Control) match can be used to match packets based on their MAC source address. As of writing this documentation, this match is a little bit limited, however, in the future this may be more evolved and may be more useful. This match can be used to match packets on the source MAC address only as previously said.
Note Do note that to use this module we explicitly load it with the -m mac option. The reason that I am saying this is that a lot of people wonder if it should not be -m mac-source, which it should not.
Table 10-21. Mac match options
| Match | –mac-source |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -m mac –mac-source 00:00:00:00:00:01 |
| Explanation | This match is used to match packets based on their MAC source address. The MAC address specified must be in the form XX:XX:XX:XX:XX:XX, else it will not be legal. The match may be reversed with an ! sign and would look like –mac-source ! 00:00:00:00:00:01. This would in other words reverse the meaning of the match, so that all packets except packets from this MAC address would be matched. Note that since MAC addresses are only used on Ethernet type networks, this match will only be possible to use for Ethernet interfaces. The MAC match is only valid in the PREROUTING, FORWARD and INPUT chains and nowhere else. |
Mark match
The mark match extension is used to match packets based on the marks they have set. A mark is a special field, only maintained within the kernel, that is associated with the packets as they travel through the computer. Marks may be used by different kernel routines for such tasks as traffic shaping and filtering. As of today, there is only one way of setting a mark in Linux, namely the MARK target in iptables. This was previously done with the FWMARK target in ipchains, and this is why people still refer to FWMARK in advanced routing areas. The mark field is currently set to an unsigned integer, or 4294967296 possible values on a 32 bit system. In other words, you are probably not going to run into this limit for quite some time.
Table 10-22. Mark match options
| Match | –mark |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -t mangle -A INPUT -m mark –mark 1 |
| Explanation | This match is used to match packets that have previously been marked. Marks can be set with the MARK target which we will discuss in the next section. All packets traveling through Netfilter get a special mark field associated with them. Note that this mark field is not in any way propagated, within or outside the packet. It stays inside the computer that made it. If the mark field matches the mark, it is a match. The mark field is an unsigned integer, hence there can be a maximum of 4294967296 different marks. You may also use a mask with the mark. The mark specification would then look like, for example, –mark 1/1. If a mask is specified, it is logically AND ed with the mark specified before the actual comparison. |
Multiport match
The multiport match extension can be used to specify multiple destination ports and port ranges. Without the possibility this match gives, you would have to use multiple rules of the same type, just to match different ports.
Note You can not use both standard port matching and multiport matching at the same time, for example you can't write: –sport 1024:63353 -m multiport –dport 21,23,80. This will simply not work. What in fact happens, if you do, is that iptables honors the first element in the rule, and ignores the multiport instruction.
Table 10-23. Multiport match options
| Match | –source-port |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m multiport –source-port 22,53,80,110 |
| Explanation | This match matches multiple source ports. A maximum of 15 separate ports may be specified. The ports must be comma delimited, as in the above example. The match may only be used in conjunction with the -p tcp or -p udp matches. It is mainly an enhanced version of the normal –source-port match. |
| Match | –destination-port |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m multiport –destination-port 22,53,80,110 |
| Explanation | This match is used to match multiple destination ports. It works exactly the same way as the above mentioned source port match, except that it matches destination ports. It too has a limit of 15 ports and may only be used in conjunction with -p tcp and -p udp. |
| Match | –port |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m multiport –port 22,53,80,110 |
| Explanation | This match extension can be used to match packets based both on their destination port and their source port. It works the same way as the –source-port and –destination-port matches above. It can take a maximum of 15 ports and can only be used in conjunction with -p tcp and -p udp. Note that the –port match will only match packets coming in from and going to the same port, for example, port 80 to port 80, port 110 to port 110 and so on. |
Owner match
The owner match extension is used to match packets based on the identity of the process that created them. The owner can be specified as the process ID either of the user who issued the command in question, that of the group, the process, the session, or that of the command itself. This extension was originally written as an example of what iptables could be used for. The owner match only works within the OUTPUT chain, for obvious reasons: It is pretty much impossible to find out any information about the identity of the instance that sent a packet from the other end, or where there is an intermediate hop to the real destination. Even within the OUTPUT chain it is not very reliable, since certain packets may not have an owner. Notorious packets of that sort are (among other things) the different ICMP responses. ICMP responses will never match.
Table 10-24. Owner match options
| Match | –cmd-owner |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m owner –cmd-owner httpd |
| Explanation | This is the command owner match, and is used to match based on the command name of the process that is sending the packet. In the example, httpd is matched. This match may also be inverted by using an exclamation sign, for example -m owner ! –cmd-owner ssh. |
| Match | –uid-owner |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m owner –uid-owner 500 |
| Explanation | This packet match will match if the packet was created by the given User ID (UID). This could be used to match outgoing packets based on who created them. One possible use would be to block any other user than root from opening new connections outside your firewall. Another possible use could be to block everyone but the http user from sending packets from the HTTP port. |
| Match | –gid-owner |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m owner –gid-owner 0 |
| Explanation | This match is used to match all packets based on their Group ID (GID). This means that we match all packets based on what group the user creating the packets is in. This could be used to block all but the users in the network group from getting out onto the Internet or, as described above, only to allow members of the http group to create packets going out from the HTTP port. |
| Match | –pid-owner |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m owner –pid-owner 78 |
| Explanation | This match is used to match packets based on the Process ID (PID) that was responsible for them. This match is a bit harder to use, but one example would be only to allow PID 94 to send packets from the HTTP port (if the HTTP process is not threaded, of course). Alternatively we could write a small script that grabs the PID from a ps output for a specific daemon and then adds a rule for it. For an example, you could have a rule as shown in the Pid-owner.txt example. |
| Match | –sid-owner |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m owner –sid-owner 100 |
| Explanation | This match is used to match packets based on the Session ID used by the program in question. The value of the SID, or Session ID of a process, is that of the process itself and all processes resulting from the originating process. These latter could be threads, or a child of the original process. So, for example, all of our HTTPD processes should have the same SID as their parent process (the originating HTTPD process), if our HTTPD is threaded (most HTTPDs are, Apache and Roxen for instance). To show this in example, we have created a small script called Sid-owner.txt. This script could possibly be run every hour or so together with some extra code to check if the HTTPD is actually running and start it again if necessary, then flush and re-enter our OUTPUT chain if needed. |
Note The pid, sid and command matching is broken in SMP kernels since they use different process lists for each processor. It might be fixed in the future however
Packet type matchThe packet type match is used to match packets based on their type. I.e., are they destined to a specific person, to everyone or to a specific group of machines or users. These three groups are generally called unicast, broadcast and multicast, as discussed in the TCP/IP repetition chapter. The match is loaded by using -m pkttype.
Table 10-25. Packet type match options
| Match | –pkt-type |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m pkttype –pkt-type unicast |
| Explanation | The –pkt-type match is used to tell the packet type match which packet type to match. It can either take unicast , broadcast or multicast as an argument, as in the example. It can also be inverted by using a ! like this: -m pkttype –pkt-type ! broadcast, which will match all other packet types. |
Realm match
The realm match is used to match packets based on the routing realm that they are part of. Routing realms are used in Linux for complex routing scenarios and setups such as when using BGP et cetera. The realm match is loaded by adding the -m realm keyword to the commandline.
A routing realm is used in Linux to classify routes into logical groups of routes. In most dedicated routers today, the Routing Information Base (RIB) and the forwarding engine are very close to eachother. Inside the kernel for example. Since Linux isn't really a dedicated routing system, it has been forced to separate its RIB and Forwarding Information Base (FIB). The RIB lives in userspace and the FIB lives inside kernelspace. Because of this separation, it becomes quite resourceheavy to do quick searches in the RIB. The routing realm is the Linux solution to this, and actually makes the system more flexible and richer.
The Linux realms can be used together with BGP and other routing protocols that delivers huge amounts of routes. The routing daemon can then sort the routes by their prefix, aspath, or source for example, and put them in different realms. The realm is numeric, but can also be named through the /etc/iproute2/rt_realms file.
Table 10-26. Realm match options
| Match | –realm |
| Kernel | 2.6 |
| Example | iptables -A OUTPUT -m realm –realm 4 |
| Explanation | This option matches the realm number and optionally a mask. If this is not a number, it will also try and resolve the realm from the /etc/iproute2/rt_realms file also. If a named realm is used, no mask may be used. The match may also be inverted by setting an exclamation sign, for example –realm ! cosmos. |
Recent match
The recent match is a rather large and complex matching system, which allows us to match packets based on recent events that we have previously matched. For example, if we would see an outgoing IRC connection, we could set the IP addresses into a list of hosts, and have another rule that allows identd requests back from the IRC server within 15 seconds of seeing the original packet.
Before we can take a closer look at the match options, let's try and explain a little bit how it works. First of all, we use several different rules to accomplish the use of the recent match. The recent match uses several different lists of recent events. The default list being used is the DEFAULT list. We create a new entry in a list with the set option, so once a rule is entirely matched (the set option is always a match), we also add an entry in the recent list specified. The list entry contains a timestamp, and the source IP address used in the packet that triggered the set option. Once this has happened, we can use a series of different recent options to match on this information, as well as update the entries timestamp, et cetera.
Finally, if we would for some reason want to remove a list entry, we would do this using the –remove match option from the recent match. All rules using the recent match, must load the recent module (-m recent) as usual. Before we go on with an example of the recent match, let's take a look at all the options.
Table 10-27. Recent match options
| Match | –name |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m recent –name examplelist |
| Explanation | The name option gives the name of the list to use. Per default the DEFAULT list is used, which is probably not what we want if we are using more than one list. |
| Match | –set |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m recent –set |
| Explanation | This creates a new list entry in the named recent list, which contains a timestamp and the source IP address of the host that triggered the rule. This match will always return success, unless it is preceded by a ! sign, in which case it will return failure. |
| Match | –rcheck |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m recent –name examplelist –rcheck |
| Explanation | The –rcheck option will check if the source IP address of the packet is in the named list. If it is, the match will return true, otherwise it returns false. The option may be inverted by using the ! sign. In the later case, it will return true if the source IP address is not in the list, and false if it is in the list. |
| Match | –update |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m recent –name examplelist –update |
| Explanation | This match is true if the source combination is available in the specified list and it also updates the last-seen time in the list. This match may also be reversed by setting the ! mark in front of the match. For example, ! –update. |
| Match | –remove |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -m recent –name example –remove |
| Explanation | This match will try to find the source address of the packet in the list, and returns true if the packet is there. It will also remove the corresponding list entry from the list. The command is also possible to inverse with the ! sign. |
| Match | –seconds |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -m recent –name example –check –seconds 60 |
| Explanation | This match is only valid together with the –check and –update matches. The –seconds match is used to specify how long since the "last seen" column was updated in the recent list. If the last seen column was older than this amount in seconds, the match returns false. Other than this the recent match works as normal, so the source address must still be in the list for a true return of the match. |
| Match | –hitcount |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -m recent –name example –check –hitcount 20 |
| Explanation | The –hitcount match must be used together with the –check or –update matches and it will limit the match to only include packets that have seen at least the hitcount amount of packets. If this match is used together with the –seconds match, it will require the specified hitcount packets to be seen in the specific timeframe. This match may also be reversed by adding a ! sign in front of the match. Together with the –seconds match, this means that a maximum of this amount of packets may have been seen during the specified timeframe. If both of the matches are inversed, then a maximum of this amount of packets may have been seen during the last minumum of seconds. |
| Match | –rttl |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -m recent –name example –check –rttl |
| Explanation | The –rttl match is used to verify that the TTL value of the current packet is the same as the original packet that was used to set the original entry in the recent list. This can be used to verify that people are not spoofing their source address to deny others access to your servers by making use of the recent match. |
| Match | –rsource |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -m recent –name example –rsource |
| Explanation | The –rsource match is used to tell the recent match to save the source address and port in the recent list. This is the default behavior of the recent match. |
| Match | –rdest |
| Kernel | 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -m recent –name example –rdest |
| Explanation | The –rdest match is the opposite of the –rsource match in that it tells the recent match to save the destination address and port to the recent list. |
I have created a small sample script of how the recent match can be used, which you can find in the Recent-match.txt section.
Briefly, this is a poor replacement for the state engine available in netfilter. This version was created with a http server in mind, but will work with any TCP connection. First we have created two chains named http-recent and http-recent-final. The http-recent chain is used in the starting stages of the connection, and for the actual data transmission, while the http-recent-final chain is used for the last and final FIN/ACK, FIN handshake.
Warning! This is a very bad replacement for the built in state engine and can not handle all of the possibilities that the state engine can handle. However, it is a good example of what can be done with the recent match without being too specific. Do not use this example in a real world environment. It is slow, handles special cases badly, and should generally never be used more than as an example.
For example, it does not handle closed ports on connection, asyncronuous FIN handshake (where one of the connected parties closes down, while the other continues to send data), etc.
Let's follow a packet through the example ruleset. First a packet enters the INPUT chain, and we send it to the http-recent chain.
The first packet should be a SYN packet, and should not have the ACK,FIN or RST bits set. Hence it is matched using the –tcp-flags SYN,ACK,FIN,RST SYN line. At this point we add the connection to the httplist using -m recent –name httplist –set line. Finally we accept the packet.
After the first packet we should receive a SYN/ACK packet to acknowledge that the SYN packet was received. This can be matched using the –tcp-flags SYN,ACK,FIN,RST SYN,ACK line. FIN and RST should be illegal at this point as well. At this point we update the entry in the httplist using -m recent –name httplist –update and finally we ACCEPT the packet.
By now we should get a final ACK packet, from the original creater of the connection, to acknowledge the SYN/ACK sent by the server. SYN, FIN and RST are illegal at this point of the connection, so the line should look like –tcp-flags SYN,ACK,FIN,RST ACK. We update the list in exactly the same way as in the previous step, and ACCEPT it.
At this point the data transmission can start. The connection should never contain any SYN packet now, but it will contain ACK packets to acknowledge the data packets that are sent. Each time we see any packet like this, we update the list and ACCEPT the packets.
The transmission can be ended in two ways, the simplest is the RST packet. RST will simply reset the connection and it will die. With FIN/ACK, the other endpoint answers with a FIN, and this closes down the connection so that the original source of the FIN/ACK can no longer send any data. The receiver of the FIN, will still be able to send data, hence we send the connection to a "final" stage chain to handle the rest.
In the http-recent-final chain we check if the packet is still in the httplist, and if so, we send it to the http-recent-final1 chain. In that chain we remove the connection from the httplist and add it to the http-recent-final list instead. If the connection has already been removed and moved over to the http-recent-final list, we send te packet to the http-recent-final2 chain.
In the final http-recent-final2 chain, we wait for the non-closed side to finish sending its data, and to close the connection from their side as well. Once this is done, the connection is completely removed.
As you can see the recent list can become quite complex, but it will give you a huge set of possibilities if need be. Still, try and remember not to reinvent the wheel. If the ability you need is already implemented, try and use it instead of trying to create your own solution.
