📄 packet-filtering-howto.txt
字号:
[1m7.3.6.2. UDP Extensions[0m
These extensions are automatically loaded if `-p udp' is specified.
It provides the options `--source-port', `--sport', `--destination-
port' and `--dport' as detailed for TCP above.
[1m7.3.6.3. ICMP Extensions[0m
This extension is automatically loaded if `-p icmp' is specified. It
provides only one new option:
[1m--icmp-type[0m
followed by an optional `!', then either an icmp type name (eg
`host-unreachable'), or a numeric type (eg. `3'), or a numeric
type and code separated by a `/' (eg. `3/3'). A list of
available icmp type names is given using `-p icmp --help'.
[1m7.3.6.4. Other Match Extensions[0m
The other extensions in the netfilter package are demonstration
extensions, which (if installed) can be invoked with the `-m' option.
[1mmac[0m
This module must be explicitly specified with `-m mac' or
`--match mac'. It is used for matching incoming packet's source
Ethernet (MAC) address, and thus only useful for packets
traversing the PREROUTING and INPUT chains. It provides only
one option:
[1m--mac-source[0m
followed by an optional `!', then an ethernet address in
colon-separated hexbyte notation, eg `--mac-source
00:60:08:91:CC:B7'.
[1mlimit[0m
This module must be explicitly specified with `-m limit' or
`--match limit'. It is used to restrict the rate of matches,
such as for suppressing log messages. It will only match a
given number of times per second (by default 3 matches per hour,
with a burst of 5). It takes two optional arguments:
[1m--limit[0m
followed by a number; specifies the maximum average number of
matches to allow per second. The number can specify units
explicitly, using `/second', `/minute', `/hour' or `/day', or
parts of them (so `5/second' is the same as `5/s').
[1m--limit-burst[0m
followed by a number, indicating the maximum burst before the
above limit kicks in.
This match can often be used with the LOG target to do rate-
limited logging. To understand how it works, let's look at the
following rule, which logs packets with the default limit
parameters:
# iptables -A FORWARD -m limit -j LOG
The first time this rule is reached, the packet will be logged; in
fact, since the default burst is 5, the first five packets will be
logged. After this, it will be twenty minutes before a packet will
be logged from this rule, regardless of how many packets reach it.
Also, every twenty minutes which passes without matching a packet,
one of the burst will be regained; if no packets hit the rule for
100 minutes, the burst will be fully recharged; back where we
started.
Note: you cannot currently create a rule with a recharge time
greater than about 59 hours, so if you set an average rate of one
per day, then your burst rate must be less than 3.
You can also use this module to avoid various denial of service
attacks (DoS) with a faster rate to increase responsiveness.
Syn-flood protection:
# iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
Furtive port scanner:
# iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
Ping of death:
# iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
This module works like a "hysteresis door", as shown in the graph
below.
rate (pkt/s)
^ .---.
| / DoS \
| / \
Edge of DoS -|.....:.........\.......................
= (limit * | /: \
limit-burst) | / : \ .-.
| / : \ / \
| / : \ / \
End of DoS -|/....:..............:.../.......\..../.
= limit | : :`-' `--'
-------------+-----+--------------+------------------> time (s)
LOGIC => Match | Didn't Match | Match
Say we say match one packet per second with a five packet burst,
but packets start coming in at four per second, for three seconds,
then start again in another three seconds.
<--Flood 1--> <---Flood 2--->
Total ^ Line __-- YNNN
Packets| Rate __-- YNNN
| mum __-- YNNN
10 | Maxi __-- Y
| __-- Y
| __-- Y
| __-- YNNN
|- YNNN
5 | Y
| Y Key: Y -> Matched Rule
| Y N -> Didn't Match Rule
| Y
|Y
0 +--------------------------------------------------> Time (seconds)
0 1 2 3 4 5 6 7 8 9 10 11 12
You can see that the first five packets are allowed to exceed the
one packet per second, then the limiting kicks in. If there is a
pause, another burst is allowed but not past the maximum rate set
by the rule (1 packet per second after the burst is used).
[1mowner[0m
This module attempts to match various characteristics of the
packet creator, for locally-generated packets. It is only valid
in the OUTPUT chain, and even then some packets (such as ICMP
ping responses) may have no owner, and hence never match.
[1m--uid-owner userid[0m
Matches if the packet was created by a process with the given
effective (numerical) user id.
[1m--gid-owner groupid[0m
Matches if the packet was created by a process with the given
effective (numerical) group id.
[1m--pid-owner processid[0m
Matches if the packet was created by a process with the given
process id.
[1m--sid-owner sessionid[0m
Matches if the packet was created by a process in the given
session group.
[1munclean[0m
This experimental module must be explicitly specified with `-m
unclean or `--match unclean'. It does various random sanity
checks on packets. This module has not been audited, and should
not be used as a security device (it probably makes things
worse, since it may well have bugs itself). It provides no
options.
[1m7.3.6.5. The State Match[0m
The most useful match criterion is supplied by the `state' extension,
which interprets the connection-tracking analysis of the
`ip_conntrack' module. This is highly recommended.
Specifying `-m state' allows an additional `--state' option, which is
a comma-separated list of states to match (the `!' flag indicates [1mnot[0m
to match those states). These states are:
[1mNEW[0m
A packet which creates a new connection.
[1mESTABLISHED[0m
A packet which belongs to an existing connection (i.e., a reply
packet, or outgoing packet on a connection which has seen
replies).
[1mRELATED[0m
A packet which is related to, but not part of, an existing
connection, such as an ICMP error, or (with the FTP module
inserted), a packet establishing an ftp data connection.
[1mINVALID[0m
A packet which could not be identified for some reason: this
includes running out of memory and ICMP errors which don't
correspond to any known connection. Generally these packets
should be dropped.
An example of this powerful match extension would be:
# iptables -A FORWARD -i ppp0 -m state ! --state NEW -j DROP
[1m7.4. Target Specifications[0m
Now we know what examinations we can do on a packet, we need a way of
saying what to do to the packets which match our tests. This is
called a rule's [1mtarget[22m.
There are two very simple built-in targets: DROP and ACCEPT. We've
already met them. If a rule matches a packet and its target is one of
these two, no further rules are consulted: the packet's fate has been
decided.
There are two types of targets other than the built-in ones:
extensions and user-defined chains.
[1m7.4.1. User-defined chains[0m
One powerful feature which iptables inherits from ipchains is the
ability for the user to create new chains, in addition to the three
built-in ones (INPUT, FORWARD and OUTPUT). By convention, user-
defined chains are lower-case to distinguish them (we'll describe how
to create new user-defined chains below in ``Operations on an Entire
Chain'').
When a packet matches a rule whose target is a user-defined chain, the
packet begins traversing the rules in that user-defined chain. If
that chain doesn't decide the fate of the packet, then once traversal
on that chain has finished, traversal resumes on the next rule in the
current chain.
Time for more ASCII art. Consider two (silly) chains: INPUT (the
built-in chain) and test (a user-defined chain).
`INPUT' `test'
---------------------------- ----------------------------
| Rule1: -p ICMP -j DROP | | Rule1: -s 192.168.1.1 |
|--------------------------| |--------------------------|
| Rule2: -p TCP -j test | | Rule2: -d 192.168.1.1 |
|--------------------------| ----------------------------
| Rule3: -p UDP -j DROP |
----------------------------
Consider a TCP packet coming from 192.168.1.1, going to 1.2.3.4. It
enters the INPUT chain, and gets tested against Rule1 - no match.
Rule2 matches, and its target is test, so the next rule examined is
the start of test. Rule1 in test matches, but doesn't specify a
target, so the next rule is examined, Rule2. This doesn't match, so
we have reached the end of the chain. We return to the INPUT chain,
where we had just examined Rule2, so we now examine Rule3, which
doesn't match either.
So the packet path is:
v __________________________
`INPUT' | / `test' v
------------------------|--/ -----------------------|----
| Rule1 | /| | Rule1 | |
|-----------------------|/-| |----------------------|---|
| Rule2 / | | Rule2 | |
|--------------------------| -----------------------v----
| Rule3 /--+___________________________/
------------------------|---
v
User-defined chains can jump to other user-defined chains (but don't
make loops: your packets will be dropped if they're found to be in a
loop).
[1m7.4.2. Extensions to iptables: New Targets[0m
The other type of extension is a target. A target extension consists
of a kernel module, and an optional extension to iptables to provide
new command line options. There are several extensions in the default
netfilter distribution:
[1mLOG[0m
This module provides kernel logging of matching packets. It
provides these additional options:
[1m--log-level[0m
Followed by a level number or name. Valid names are (case-
insensitive) `debug', `info', `notice', `warning', `err',
`crit', `alert' and `emerg', corresponding to numbers 7
through 0. See the man page for syslog.conf for an
explanation of these levels. The default is `warning'.
[1m--log-prefix[0m
Followed by a string of up to 29 characters, this message is
sent at the start of the log message, to allow it to be
uniquely identified.
This module is most useful after a limit match, so you don't
flood your logs.
[1mREJECT[0m
This module has the same effect as `DROP', except that the
sender is sent an ICMP `port unreachable' error message. Note
that the ICMP error message is not sent if (see RFC 1122):
o The packet being filtered was an ICMP error message in the
first place, or some unknown ICMP type.
o The packet being filtered was a non-head fragment.
o We've sent too many ICMP error messages to that destination
recently (see /proc/sys/net/ipv4/icmp_ratelimit).
REJECT also takes a `--reject-with' optional argument which
alters the reply packet used: see the manual page.
[1m7.4.3. Special Built-In Targets[0m
There are two special built-in targets: RETURN and QUEUE.
RETURN has the same effect of falling off the end of a chain: for a
rule in a built-in chain, the policy of the chain is executed. For a
rule in a user-defined chain, the traversal continues at the previous
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -