Текст книги "Iptables Tutorial 1.2.2"
Автор книги: Oskar Andreasson
Жанр:
Интернет
сообщить о нарушении
Текущая страница: 15 (всего у книги 30 страниц)
The state match extension is used in conjunction with the connection tracking code in the kernel. The state match accesses the connection tracking state of the packets from the conntracking machine. This allows us to know in what state the connection is, and works for pretty much all protocols, including stateless protocols such as ICMP and UDP. In all cases, there will be a default timeout for the connection and it will then be dropped from the connection tracking database. This match needs to be loaded explicitly by adding a -m state statement to the rule. You will then have access to one new match called state. The concept of state matching is covered more fully in the The state machine chapter, since it is such a large topic.
Table 10-28. State match options
| Match | –state |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -m state –state RELATED,ESTABLISHED |
| Explanation | This match option tells the state match what states the packets must be in to be matched. There are currently 4 states that can be used. INVALID, ESTABLISHED, NEW and RELATED. INVALID means that the packet is associated with no known stream or connection and that it may contain faulty data or headers. ESTABLISHED means that the packet is part of an already established connection that has seen packets in both directions and is fully valid. NEW means that the packet has or will start a new connection, or that it is associated with a connection that has not seen packets in both directions. Finally, RELATED means that the packet is starting a new connection and is associated with an already established connection. This could for example mean an FTP data transfer, or an ICMP error associated with a TCP or UDP connection. Note that the NEW state does not look for SYN bits in TCP packets trying to start a new connection and should, hence, not be used unmodified in cases where we have only one firewall and no load balancing between different firewalls. However, there may be times where this could be useful. For more information on how this could be used, read the The state machine chapter. |
Tcpmss match
The tcpmss match is used to match a packet based on the Maximum Segment Size in TCP. This match is only valid for SYN and SYN/ACK packets. For a more complete explanation of the MSS value, see the TCP options appendix, the RFC 793 – Transmission Control Protocol and the RFC 1122 – Requirements for Internet Hosts – Communication Layers documents. This match is loaded using -m tcpmss and takes only one option.
Table 10-29. Tcpmss match options
| Match | –mss |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp –tcp-flags SYN,ACK,RST SYN -m tcpmss –mss 2000:2500 |
| Explanation | The –mss option tells the tcpmss match which Maximum Segment Sizes to match. This can either be a single specific MSS value, or a range of MSS values separated by a :. The value may also be inverted as usual using the ! sign, as in the following example: |
| -m tcpmss ! –mss 2000:2500 | |
| This example will match all MSS values, except for values in the range 2000 through 2500. |
Tos match
The TOS match can be used to match packets based on their TOS field. TOS stands for Type Of Service, consists of 8 bits, and is located in the IP header. This match is loaded explicitly by adding -m tos to the rule. TOS is normally used to inform intermediate hosts of the precedence of the stream and its content (it doesn't really, but it informs of any specific requirements for the stream, such as it having to be sent as fast as possible, or it needing to be able to send as much payload as possible). How different routers and administrators deal with these values depends. Most do not care at all, while others try their best to do something good with the packets in question and the data they provide.
Table 10-30. Tos match options
| Match | –tos |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A INPUT -p tcp -m tos –tos 0x16 |
| Explanation | This match is used as described above. It can match packets based on their TOS field and their value. This could be used, among other things together with the iproute2 and advanced routing functions in Linux, to mark packets for later usage. The match takes a hex or numeric value as an option, or possibly one of the names resulting from 'iptables -m tos -h'. At the time of writing it contained the following named values: Minimize-Delay 16 (0x10), Maximize-Throughput 8 (0x08), Maximize-Reliability 4 (0x04), Minimize-Cost 2 (0x02), and Normal-Service 0 (0x00). Minimize-Delay means to minimize the delay in putting the packets through – example of standard services that would require this include telnet, SSH and FTP-control. Maximize-Throughput means to find a path that allows as big a throughput as possible – a standard protocol would be FTP-data. Maximize-Reliability means to maximize the reliability of the connection and to use lines that are as reliable as possible – a couple of typical examples are BOOTP and TFTP. Minimize-Cost means minimizing the cost of packets getting through each link to the client or server; for example finding the route that costs the least to travel along. Examples of normal protocols that would use this would be RTSP (Real Time Stream Control Protocol) and other streaming video/radio protocols. Finally, Normal-Service would mean any normal protocol that has no special needs. |
Ttl match
The TTL match is used to match packets based on their TTL (Time To Live) field residing in the IP headers. The TTL field contains 8 bits of data and is decremented once every time it is processed by an intermediate host between the client and recipient host. If the TTL reaches 0, an ICMP type 11 code 0 (TTL equals 0 during transit) or code 1 (TTL equals 0 during reassembly) is transmitted to the party sending the packet and informing it of the problem. This match is only used to match packets based on their TTL, and not to change anything. The latter, incidentally, applies to all kinds of matches. To load this match, you need to add an -m ttl to the rule.
Table 10-31. Ttl match options
| Match | –ttl-eq |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m ttl –ttl-eq 60 |
| Explanation | This match option is used to specify the TTL value to match exactly. It takes a numeric value and matches this value within the packet. There is no inversion and there are no other specifics to match. It could, for example, be used for debugging your local network – e.g. LAN hosts that seem to have problems connecting to hosts on the Internet – or to find possible ingress by Trojans etc. The usage is relatively limited, however; its usefulness really depends on your imagination. One example would be to find hosts with bad default TTL values (could be due to a badly implemented TCP/IP stack, or simply to misconfiguration). |
| Match | –ttl-gt |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m ttl –ttl-gt 64 |
| Explanation | This match option is used to match any TTL greater than the specified value. The value can be between 0 and 255 and the match can not be inverted. It could, for example, be used for matching any TTL greater than a specific value and then force them to a standardized value. This could be used to overcome some simple forms of spying by ISP's to find out if you are running multiple machines behind a firewall, against their policies. |
| Match | –ttl-lt |
| Kernel | 2.3, 2.4, 2.5 and 2.6 |
| Example | iptables -A OUTPUT -m ttl –ttl-lt 64 |
| Explanation | The –ttl-lt match is used to match any TTL smaller than the specified value. It is pretty much the same as the –ttl-gt match, but as already stated; it matches smaller TTL's. It could also be used in the same way as the –ttl-gt match, or to simply homogenize the packets leaving your network in general. |
Unclean match
The unclean match takes no options and requires no more than explicitly loading it when you want to use it. Note that this option is regarded as experimental and may not work at all times, nor will it take care of all unclean packages or problems. The unclean match tries to match packets that seem malformed or unusual, such as packets with bad headers or checksums and so on. This could be used to DROP connections and to check for bad streams, for example; however you should be aware that it could possibly break legal connections.
What's next?
The last chapter has been about the matches that can be used in iptables and what they are capable of doing. The matching capability of iptables and netfilter is extremely well developed and very flexible as you have seen. The next chapter will discuss the targets in detail and what they are able to do. You will notice in that chapter as well the capabilities of Linux firewalling.
Chapter 11. Iptables targets and jumps
The target/jumps tells the rule what to do with a packet that is a perfect match with the match section of the rule. There are a couple of basic targets, the ACCEPT and DROP targets, which we will deal with first. However, before we do that, let us have a brief look at how a jump is done.
The jump specification is done in exactly the same way as in the target definition, except that it requires a chain within the same table to jump to. To jump to a specific chain, it is of course a prerequisite that that chain exists. As we have already explained, a user-defined chain is created with the -N command. For example, let's say we create a chain in the filter table called tcp_packets, like this:
iptables -N tcp_packets
We could then add a jump target to it like this:
iptables -A INPUT -p tcp -j tcp_packets
We would then jump from the INPUT chain to the tcp_packets chain and start traversing that chain. When/If we reach the end of that chain, we get dropped back to the INPUT chain and the packet starts traversing from the rule one step below where it jumped to the other chain (tcp_packets in this case). If a packet is ACCEPTed within one of the sub chains, it will be ACCEPT'ed in the superset chain also and it will not traverse any of the superset chains any further. However, do note that the packet will traverse all other chains in the other tables in a normal fashion. For more information on table and chain traversing, see the Traversing of tables and chains chapter.
Targets on the other hand specify an action to take on the packet in question. We could for example, DROP or ACCEPT the packet depending on what we want to do. There are also a number of other actions we may want to take, which we will describe further on in this section. Jumping to targets may incur different results, as it were. Some targets will cause the packet to stop traversing that specific chain and superior chains as described above. Good examples of such rules are DROP and ACCEPT. Rules that are stopped, will not pass through any of the rules further on in the chain or in superior chains. Other targets, may take an action on the packet, after which the packet will continue passing through the rest of the rules. A good example of this would be the LOG, ULOG and TOS targets. These targets can log the packets, mangle them and then pass them on to the other rules in the same set of chains. We might, for example, want this so that we in addition can mangle both the TTL and the TOS values of a specific packet/stream. Some targets will accept extra options (What TOS value to use etc), while others don't necessarily need any options – but we can include them if we want to (log prefixes, masquerade-to ports and so on). We will try to cover all of these points as we go through the target descriptions. Let us have a look at what kinds of targets there are.
ACCEPT target
This target needs no further options. As soon as the match specification for a packet has been fully satisfied, and we specify ACCEPT as the target, the rule is accepted and will not continue traversing the current chain or any other ones in the same table. Note however, that a packet that was accepted in one chain might still travel through chains within other tables, and could still be dropped there. There is nothing special about this target whatsoever, and it does not require, nor have the possibility of, adding options to the target. To use this target, we simply specify -j ACCEPT.
Note Works under Linux kernel 2.3, 2.4, 2.5 and 2.6.
CLASSIFY target
The CLASSIFY target can be used to classify packets in such a way that can be used by a couple of different qdiscs (Queue Disciplines). For example, atm, cbq, dsmark, pfifo_fast, htb and the prio qdiscs. For more information about qdiscs and traffic controlling, visit the Linux Advanced Routing and Traffic Control HOW-TO webpage.
The CLASSIFY target is only valid in the POSTROUTING chain of the mangle table.
Table 11-1. CLASSIFY target options
| Option | –set-class |
| Example | iptables -t mangle -A POSTROUTING -p tcp –dport 80 -j CLASSIFY –set-class 20:10 |
| Explanation | The CLASSIFY target only takes one argument, the –set-class. This tells the target how to class the packet. The class takes 2 values separated by a coma sign, like this MAJOR:MINOR. Once again, if you want more information on this, check the Linux Advanced Routing and Traffic Control HOW-TO webpage. |
Note Works under Linux kernel 2.5 and 2.6.
CLUSTERIP target
The CLUSTERIP target is used to create simple clusters of nodes answering to the same IP and MAC address in a round robin fashion. This is a simple form of clustering where you set up a Virtual IP (VIP) on all hosts participating in the cluster, and then use the CLUSTERIP on each host that is supposed to answer the requests. The CLUSTERIP match requires no special load balancing hardware or machines, it simply does its work on each host part of the cluster of machines. It is a very simple clustering solution and not suited for large and complex clusters, neither does it have built in heartbeat handling, but it should be easily implemented as a simple script.
All servers in the cluster uses a common Multicast MAC for a VIP, and then a special hash algorithm is used within the CLUSTERIP target to figure out who of the cluster participants should respond to each connection. A Multicast MAC is a MAC address starting with 01:00:5e as the first 24 bits. an example of a Multicast MAC would be 01:00:5e:00:00:20. The VIP can be any IP address, but must be the same on all hosts as well.
Important Remember that the CLUSTERIP might break protocols such as SSH et cetera. The connection will go through properly, but if you try the same time again to the same host, you might be connected to another machine in the cluster, with a different keyset, and hence your ssh client might refuse to connect or give you errors. For this reason, this will not work very well with some protocols, and it might be a good idea to add separate addresses that can be used for maintenance and administration. Another solution is to use the same SSH keys on all hosts participating in the cluster.
The cluster can be loadbalanced with three kinds of hashmodes. The first one is only source IP (sourceip), the second is source IP and source port (sourceip-sourceport) and the third one is source IP, source port and destination port (sourceip-sourceport-destport). The first one might be a good idea where you need to remember states between connections, for example a webserver with a shopping cart that keeps state between connections, this load-balancing might become a little bit uneven – different machines might get a higher loads than others, et cetera – since connections from the same source IP will go to the same server. The sourceip-sourceport hash might be a good idea where you want to get the load-balancing a little bit more even, and where state does not have to be kept between connections on each server. For example, a large informational webpage with perhaps a simple search engine might be a good idea here. The third and last hashmode, sourceip-sourceport-destport, might be a good idea where you have a host with several services running that does not require any state to be preserved between connections. This might for example be a simple ntp, dns and www server on the same host. Each connection to each new destination would hence be "renegotiated" – actually no negotiation goes on, it is basically just a round robin system and each host receives one connection each.
Each CLUSTERIP cluster gets a separate file in the /proc/net/ipt_CLUSTERIP directory, based on the VIP of the cluster. If the VIP is 192.168.0.5 for example, you could cat /proc/net/ipt_CLUSTERIP/192.168.0.5 to see which nodes this machine is answering for. To make the machine answer for another machine, lets say node 2, add it using echo "+2" >> /proc/net/ipt_CLUSTERIP/192.168.0.5. To remove it, run echo "-2" >> /proc/net/ipt_CLUSTERIP/192.168.0.5.
Table 11-2. CLUSTERIP target options
| Option | –new |
| Example | iptables -A INPUT -p tcp -d 192.168.0.5 –dport 80 -j CLUSTERIP –new ... |
| Explanation | This creates a new CLUSTERIP entry. It must be set on the first rule for a VIP, and is used to create a new cluster. If you have several rules connecting to the same CLUSTERIP you can omit the –new keyword in any secondary references to the same VIP. |
| Option | –hashmode |
| Example | iptables -A INPUT -p tcp -d 192.168.0.5 –dport 443 -j CLUSTERIP –new –hashmode sourceip ... |
| Explanation | The –hashmode keyword specifies the kind of hash that should be created. The hashmode can be any of the following three. |
| • sourceip | |
| • sourceip-sourceport | |
| • sourceip-sourceport-destport | |
| The hashmodes has been extensively explained above. Basically, sourceip will give better performance and simpler states between connections, but not as good load-balancing between the machines. sourceip-sourceport will give a slightly slower hashing and not as good to maintain states between connections, but will give better load-balancing properties. The last one may create very slow hashing that consumes a lot of memory, but will on the other hand also create very good load-balancing properties. | |
| Option | –clustermac |
| Example | iptables -A INPUT -p tcp -d 192.168.0.5 –dport 80 -j CLUSTERIP –new –hashmode sourceip –clustermac 01:00:5e:00:00:20 ... |
| Explanation | The MAC address that the cluster is listening to for new connections. This is a shared Multicast MAC address that all the hosts are listening to. See above for a deeper explanation of this. |
| Option | –total-nodes |
| Example | iptables -A INPUT -p tcp -d 192.168.0.5 –dport 80 -j CLUSTERIP –new –hashmode sourceip –clustermac 01:00:5e:00:00:20 –total-nodes 2 ... |
| Explanation | The –total-nodes keyword specifies how many hosts are participating in the cluster and that will answer to requests. See above for a deeper explanation. |
| Option | –local-node |
| Example | iptables -A INPUT -p tcp -d 192.168.0.5 –dport 80 -j CLUSTERIP –new –hashmode sourceip –clustermac 01:00:5e:00:00:20 –total-nodes 2 –local-node 1 |
| Explanation | This is the number that this machine has in the cluster. The cluster answers in a round-robin fashion, so once a new connection is made to the cluster, the next machine answers, and then the next after that, and so on. |
| Option | –hash-init |
| Example | iptables -A INPUT -p tcp -d 192.168.0.5 –dport 80 -j CLUSTERIP –new –hashmode sourceip –clustermac 01:00:5e:00:00:20 –hash-init 1234 |
| Explanation | Specifies a random seed for hash initialization. |
Warning This target is in violation of the RFC 1812 – Requirements for IP Version 4 Routers RFC, so be wary of any problems that may arise. Specifically, section 3.3.2 which specifies that a router must never trust another host or router that says that it is using a multicast mac.
Note Works under late Linux 2.6 kernels, marked experimental.
CONNMARK target
The CONNMARK target is used to set a mark on a whole connection, much the same way as the MARK target does. It can then be used together with the connmark match to match the connection in the future. For example, say we see a specific pattern in a header, and we don't want to mark just that packet, but the whole connection. The CONNMARK target is a perfect solution in that case.
The CONNMARK target is available in all chains and all tables, but remember that the nat table is only traversed by the first packet in a connection, so the CONNMARK target will have no effect if you try to use it for subsequent packets after the first one in here. It can take one of four different options as seen below.
Table 11-3. CONNMARK target options
| Option | –set-mark |
| Example | iptables -t nat -A PREROUTING -p tcp –dport 80 -j CONNMARK –set-mark 4 |
| Explanation | This option sets a mark on the connection. The mark can be an unsigned long int, which means values between 0 and 4294967295l is valid. Each bit can also be masked by doing –set-mark 12/8. This will only allow the bits in the mask to be set out of all the bits in the mark. In this example, only the 4th bit will be set, not the 3rd. 12 translates to 1100 in binary, and 8 to 1000, and only the bits set in the mask are allowed to be set. Hence, only the 4th bit, or 8, is set in the actual mark. |
| Option | –save-mark |
| Example | iptables -t mangle -A PREROUTING –dport 80 -j CONNMARK –save-mark |
| Explanation | The –save-mark target option is used to save the packet mark into the connection mark. For example, if you have set a packet mark with the MARK target, you can then move this mark to mark the whole connection with the –save-mark match. The mark can also be masked by using the –mask option described further down. |
| Option | –restore-mark |
| Example | iptables -t mangle -A PREROUTING –dport 80 -j CONNMARK –restore-mark |
| Explanation | This target option restores the packet mark from the connection mark as defined by the CONNMARK. A mask can also be defined using the –mask option as seen below. If a mask is set, only the masked options will be set. Note that this target option is only valid for use in the mangle table. |
| Option | –mask |
| Example | iptables -t mangle -A PREROUTING –dport 80 -j CONNMARK –restore-mark –mask 12 |
| Explanation | The –mask option must be used in unison with the –save-mark and –restore-mark options. The –mask option specifies an and-mask that should be applied to the mark values that the other two options will give. For example, if the restored mark from the above example would be 15, it would mean that the mark was 1111 in binary, while the mask is 1100. 1111 and 1100 equals 1100. |
Note Works under Linux kernel 2.6.
