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. |
AH/ESP match
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
• 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. |