Oskar Andreasson - Iptables Tutorial 1.2.2
- Название:Iptables Tutorial 1.2.2
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Oskar Andreasson - Iptables Tutorial 1.2.2 краткое содержание
Iptables Tutorial 1.2.2 - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
• 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.
NoteIn 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.
ImportantTo 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. |
NotePlease note that the --dscp and --dscp-class options are mutually exclusive and can not be used in conjunction with each other.
Ecn match
The 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.
Читать дальшеИнтервал:
Закладка: