Iptables руководство на русском - Большая энциклопедия инструкций и руководств

��blueflux@koffein.net
��Copyright (C) 2001-2003 Oskar Andreasson
��

��: ��

�� tar.gz ��

�� : http://iptables-tutorial.frozentux.net
.

�� /��
�� , � �� ,
�� GNU Free Documentation License, �� 1.1.
�� «��»
� �� , � �� ,
�� «Original Author: Oskar
Andreasson», �� GNU Free Documentation License
�� «GNU
Free Documentation License».

��
GNU General Public License. ��
�� /��
� �� GNU General Public License ��
2.

�� , ��
�� , �� . ��
�� GNU General Public
License.

� �� GNU
General Public License, � �� «GNU General Public
License»; � ��
�� Free Software Foundation, Inc., 59 Temple Place, Suite
330, Boston, MA 02111-1307 USA

��

�� , � ��
�� (Ninel). ��
��, �� -�� .

��-�� — �� Linux ��
�� , ��
�� .

��

� ��, ��
�� , ��
�� , � �� . � � ��
�� ipchains � iptables �� .
�� , ��
�� , �� , ��
�� FTP (passive FTP) �� DCC � IRC (outgoing DCC in IRC), ��
��
�� . � ��
� �� ‘��’, �� ipchains,
� �� iptables ��
��. �� , ��
�� ipchains � ipfwadm
‘��’ �� iptables!

��

�� , ��
�� iptables. ��
�� iptables �� netfilter. ��
�� , ��
��, � �� , ��
�� . �� iptables �
netfilter �� , �� —
�� «��». ��
�� Netfilter.

�� , ��
��, �� , ��
�� -�� netfilter. ��
�� — ��
��, � �� . ��, � ��
�� , �� Apache 1.2.12
�� HTTP �� (�� , ��
�� , �� ).

�� ,
�� iptables.
��
patch-o-matic �� , ��
�� , �� .
��
�� patch-o-matic, ��
��, �� patch-o-matic,
�� Netfilter.

��

��
�� Linux/Unix, �� .
�� , �� — ��
��
��.

� ��, �� , ��
��
��, �� , � �� -��
�� .

��

� ��
�� :

��, �� , � ��, ��
�� , ��
��, �� , ��
��:
```
[blueflux@work1 neigh]$ ls
default  eth0  lo
[blueflux@work1 neigh]$
    
```
�� ��  .
�� , � ��
��
(��: �� (loopback) ��), �� ��.
�� :
/usr/local/bin/iptables.

�� 1. ��

1.1. ��
��

�� , � ��, ��
HOWTO �� iptables � ��
�� (netfilter), �� 2.4.x
Linux. �� , � ��
�� , ��
�� (state matching). ��
�� rc.firewall.txt, ��
�� /etc/rc.d/. �� , �� ,
�� , ��
masquerading HOWTO.

�� rc.flush-iptables.txt,
�� , �� , ��
��, �� .

1.2. ��

� �� (Marc Boucher) �
�� netfilter. ��
��, ��
�� , ��
�� boingworld.com, � ��
�� frozentux.net. � ��
�� , ��, ��
�� iptables
�� . ��
�� rc.firewall.txt, �� , ��
�� — �� iptables. � ��
�� . ��
�� , ��
��. �, �� , �� ,
�� .

1.3. ��, ��
��

�� , ��
�� , �� .

DNAT — �� . Destination Network Address Translation —
�� . DNAT — ��
�� . ��
�� SNAT. �� — ��
�� IP-��
��
�� .

«��» (Stream) — ��
�� , ��
�� . � ��
��, �� 2 ��
� �� . � �� TCP ��
��, �� SYN ��
�� SYN/ACK ��. ��
� �� SYN �� ICMP Host
unreachable. �� , � ��
�� .

SNAT — �� . Source Network Address Translation —
�� . SNAT — ��
�� . �� —
�� IP-��
�� . � ��
�� IP-��, �� IPv4, �� , �
�� (�� IPv6 ��
��).

«��» (State) — ��
�� , � �� ,
�� RFC 793 — RFC 793 — Transmission Control
Protocol, � �� , ��
netfilter/iptables. �� ,
�� , ��
�� , �� Netfilter, ��
�� RFC 793.

«�� » (User space) — ��
�� , ��
�� , ��: �� iptables -h ��
�� , � �� iptables -A FORWARD -p tcp -j
ACCEPT �� (��) � �� ,
��
��.

«�� » (Kernel space) — � ��
�� , ��
«�� ». ��
�� — � �� .

«Userland» — ��. «��
��».

�� 2. ��

��
��, �� netfilter � iptables �� Linux ��. ��
��
�� (firewall).

2.1. �� iptables

�� iptables ��
�� Netfilter. �� , ��
iptables ��
�� Linux-��. ��
��.

2.2. ��

�� iptables, � �� make config ��
(make menuconfig �� make xconfig ��. ��.), � ��
�� :

CONFIG_PACKET — ��
�� , ��
�� , ��: tcpdump �� snort.

�� , �� CONFIG_PACKET ��
�� iptables, ��, ��
�� , � �� . ��
�� , �� .

CONFIG_NETFILTER — ��
��, ��
�� (firewall) �� (gateway) �
��. �� , �� ,
�� !

� �� ,
�.�. �� Ethernet, PPP � SLIP. ��
�� iptables, ��
��
�� . ��
�� 2.4.9 � �� :

CONFIG_IP_NF_CONNTRACK —
�� . �� , ��
��, ��
�� (NAT � Masquerading). ��
�� (firewall) �� , ��
�� . � ��, ��
�� rc.firewall.txt.

CONFIG_IP_NF_FTP — ��
FTP ��. �� FTP �� , ��
�� . ��
�� , ��
�� FTP �� (firewall).

CONFIG_IP_NF_IPTABLES — ��
�� ,
�� (NAT) � ��
(masquerading). ��
iptables.

CONFIG_IP_NF_MATCH_LIMIT — ��
�� , �� rc.firewall.txt. ��
��
�� . ��, -m limit —limit 3/minute
��, �� 3-�
�� . �� , ��
�� «��
��».

CONFIG_IP_NF_MATCH_MAC — ��
�� , �� MAC-��. �� , ��
��
Ethernet-��, �� , ��
�� , �� MAC-�� (�.�. � ��
�� ). ��, ��, ��
�� rc.firewall.txt ��
�� .

CONFIG_IP_NF_MATCH_MARK —
�� MARK. ��, ��
�� MARK ��
�� , � ��, � �� , �
�� , ��
�� . ��
�� MARK ��
��.

CONFIG_IP_NF_MATCH_MULTIPORT —
��
��
��/��.

CONFIG_IP_NF_MATCH_TOS — ��
�� , ��
�� TOS � ��. �� TOS �� Type Of
Service. ��
��
mangle �� ip/tc.

CONFIG_IP_NF_MATCH_TCPMSS — ��
�� MSS � TCP-��.

CONFIG_IP_NF_MATCH_STATE — ��
��
ipchains. ��
�� TCP ��, ��
�� (state). � ��, ��, ��
�� TCP ��, � �� , ��
�� ESTABLISHED (��
�� — ��. ��). ��
� �� rc.firewall.txt.

CONFIG_IP_NF_MATCH_UNCLEAN —
�� IP, TCP, UDP � ICMP ��
��, «��», ��. ��
�� , � ��, �� «��»
�� . �� , ��
��
�� , ��
�� , �� «��» ��
�� .

CONFIG_IP_NF_MATCH_OWNER —
�� «��» �� (socket). ��
��, �� root ��
� Internet. ��
iptables. �� , ��
��
�� .

CONFIG_IP_NF_FILTER — ��
�� filter � ��
�� . � ��
INPUT, FORWARD � OUTPUT. �� , ��
�� .

CONFIG_IP_NF_TARGET_REJECT —
�� REJECT, ��
ICMP-��
�� , �� .
��, �� TCP ��, � �� UDP � ICMP, ��
�� TCP RST.

CONFIG_IP_NF_TARGET_MIRROR —
�� (��).
��, �� MIRROR �� , �� HTTP �� INPUT (�.�. �� WEB-�� .
��.), �� (��) �, �
��, ��
��. (�� «��»: ��
�� WEB-��, ��
��, �� , � �.�. .
��-�� , ��
�� , ��
�� , � �� , �� MIRROR ��
��
��. ��.)

CONFIG_IP_NF_NAT — ��
�� . � ��
��
�� , �� IP-��. ��
�� rc.firewall.txt.

CONFIG_IP_NF_TARGET_MASQUERADE —
��. � �� NAT, ��
��, �� IP-�� ,
�.�. �� DHCP, PPP, SLIP �� -��
��, ��
IP-��. ��
�� , �� NAT, ��
��, ��
�� IP-��.

CONFIG_IP_NF_TARGET_REDIRECT —
��. ��
��. �� , ��
�� , ��
�� (��-�� .
��.). �� , ��
«��
��».

CONFIG_IP_NF_TARGET_LOG —
�� LOG � iptables. ��
��
�� (syslog). ��
�� .

CONFIG_IP_NF_TARGET_TCPMSS — ��
�� ,
�� (Internet Service
Providers), �� ICMP Fragmentation Needed ��. �
��
�� web-��, ssh �� , � ��
scp �� . ��
��
�� TCPMSS �� MSS (Maximum Segment Size) (�� MSS
�� MTU �� 40
�� . ��.). ��
�� , �� netfilter �� «��
�� »
(«criminally braindead ISPs or servers») � ��
�� .

CONFIG_IP_NF_COMPAT_IPCHAINS —
�� ipchains. �� , ��
��
2.6.x.

CONFIG_IP_NF_COMPAT_IPFWADM —
�� ipfwadm, ��
�� .

�� , � ��
��. �� 2.4.9. ��
�� — ��
�� patch-o-matic, ��
�� Netfilter. Patch-o-matic — �� ,
��, �� , � ��
�� .

�� rc.firewall.txt ��
��
�� . ��
��, �� , ��
� �� .

CONFIG_PACKET
CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_FTP
CONFIG_IP_NF_IRC
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_TARGET_LOG
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_TARGET_MASQUERADE

��
�� rc.firewall.txt ��
��, ��
�� . ��
�� .

2.3. ��

� �� (��)
�� iptables. ��
��
�� . ��
�� iptables, �� — Red Hat.
��, � RedHat �� , ��
��
��.

2.3.1. ��

�� iptables �� . ��
�� iptables 1.2.6a � �� 2.4.
�� , �� bzip2 -cd iptables-1.2.6a.tar.bz2 | tar
-xvf — (��
tar -xjvf
iptables-1.2.6a.tar.bz2). ��
��, �� iptables-1.2.6a. ��
�� iptables-1.2.6a/INSTALL, ��
��
��.

��
�� . ��, �� ,
�� «��»
(patches) �� . �� ,
��, �� , ��
��.

��
��
�� , ��
��
��.

�� , �� (��,
�� root)

make pending-patches
KERNEL_DIR=/usr/src/linux/

�� KERNEL_DIR ��
�� . �� /usr/src/linux/. ��
�� , ��,
��, �� .

��
�� , ��
� �� , �� , ��
�� :

make most-of-pom
KERNEL_DIR=/usr/src/linux/

� ��
��
�� , �� netfilter �� patch-o-matic. ��
�� «��» �� patch-o-matic, ��
�� :

make patch-o-matic
KERNEL_DIR=/usr/src/linux/

��
�� «��» ��
�� -��, �� «��»
�� , � �� — ��
�� .

�� ,
��
��, �� patch-o-matic ��
�� , � � ��
�� . ��
�� , ��
�� .

�� , ��
�� , ��
��. ��
��, ��
�� . � ��, ��
��
iptables.

�� iptables, �� :

make
KERNEL_DIR=/usr/src/linux/

�� , ��
�� , ��
�� Netfilter mailing list, ��
�� . �� , ��
�� , ��
��. �� — ��
��, �� . ��
«��».

�� , ��
�� (binaries), ��
�� :

make install
KERNEL_DIR=/usr/src/linux/

��, �� -�� ! ��
�� iptables ��
�� , ��
�� . ��
�� INSTALL.

2.3.2. �� Red Hat 7.1

RedHAt 7.1, � �� 2.4.x ��
�� netfilter � iptables. ��, ��
�� , ��
�� ipchains. ��
�� — �� ipchains � ��
iptables.

�� iptables � Red Hat 7.1
�� , ��
�� .

�� ipchains, ��
�� . ��
��, ��
�� /etc/rc.d/. �� ,
�� :

chkconfig —level 0123456 ipchains
off

� �� , � ��
��, �� /etc/rc.d/init.d/ipchains, �� S
(�� , ��
�� ) �� K (�� Kill,
�� , �� , ��
�� . ��
�� .

�� ipchains ��-��
��. �� , ��
�� :

service ipchains stop

� � �� iptables. �� , ��-��,
�� ,
�� . ��
2, 3 � 5. �� :

2. �� NFS ��
�� , �� 3, �� .
3. ��
��.
5. X11. ��
�� Xwindows.

�� iptables ��
�� :

chkconfig —level 235 iptables
on

�� , ��
�� iptables: �� 1 —
�� , ��
� �� , �� «��»
«��» ��. �� 4 — ��
��. �� 6 — ��
��
��.

�� iptables �� :

service iptables start

��, �� iptables, ��
�� . �� Red Hat
7.1 �� , ��-��: ��
/etc/rc.d/init.d/iptables, ��
�� — ��
iptables �� RPM-�� , �
��-��: �� iptables-save, ��
��
�� .

� ��, ��
�� iptables, ��
�� start ��
/etc/rc.d/init.d/iptables (��
�� ) �� start(). ��
�� — ��
�� stop) �� stop(). ��
�� restart � condrestart. ��
��, �� iptables �� RPM-��
�� , ��
��, �� /etc/rc.d/init.d/iptables.

�� . ��
�� . �� — ��
� �� , �� iptables, ��
��. �� iptables-save. ��
�� iptables-save >
/etc/sysconfig/iptables. � ��, ��
�� /etc/sysconfig/iptables, ��
�� iptables.
��
service iptables save, ��
�� . ��,
�� , �� iptables �� rc.d
�� iptables-restore ��
�� /etc/sysconfig/iptables.

� ��, � �� , ��
�� ipchains � iptables. ��
�� , �� «��» ��
�� iptables � �� .
�� iptables ��
�� , ��
�� . �� , �� RPM ��
�� ,
�� , � ��
«��» ��. ��
�� iptables ��
��:

rpm -e iptables

�� ipchains, ��
�� .

rpm -e ipchains

�� 3. ��
� ��

� ��
�� . ��
�� , �� ,
��
�� DNAT, SNAT � �� TOS.

3.1. ��

�� , ��
�� , ��
�� . ��
��
��, �� . ��
�� :

�� 3-1. ��
��

��	��	��	��
1	�	�	�� (�.�. ��)
2	�	�	�� (��, eth0)
3	mangle	PREROUTING	�� �� , �� �� TOS � ��..
4	nat	PREROUTING	�� �� (Destination Network Address Translation). Source Network Address Translation �� , � �� ��. �� ��
5	�	�	�� ��, �.�. � �� �� — �� ��.
6	mangle	FORWARD	�� FORWARD �� mangle, �� ��, �� � �� �� .
7	Filter	FORWARD	� �� FORWARD �� ��, �� �� . �� ��, �� �� , �� �� .
8	mangle	POSTROUTING	�� �� �� .
9	nat	POSTROUTING	�� �� Source Network Address Translation. �� �� . �� � �� (Masquerading).
10	�	�	�� (��, eth1).
11	�	�	�� (�� LAN).

�� , �� ,
�� . ��
�� , �� iptables �� , ��
�� iptables. ��, ��
�� , ��
�� . �� FORWARD �� , ��
�� / ��. ��
INPUT �� , ��
��! �� ,
�� !

� �� ,
�� /��:

�� 3-2. ��
��

��	��	��	��
1	�	�	�� (�.�. ��)
2	�	�	�� (��, eth0)
3	mangle	PREROUTING	�� �� , �� �� TOS � ��.
4	nat	PREROUTING	�� (Destination Network Address Translation). �� �� .
5	�	�	�� .
6	mangle	INPUT	�� INPUT �� mangle. �� �� �� .
7	filter	INPUT	�� ��. ��, �� , �� , �� , �� ��.
8	�	�	�� /�� (�.�., ��-�� -��)

�� , ��
INPUT, � �� FORWARD.

� � �� ,
�� .

�� 3-3. �� 

��	��	��	��
1	�	�	�� (�.�., ��-�� -��).
2	�	�	�� . �� �� — �� , �� .
3	mangle	OUTPUT	�� �� . �� �� .
4	nat	OUTPUT	�� �� (NAT) � ��, �� �� .
5	Filter	OUTPUT	�� ��.
6	mangle	POSTROUTING	�� POSTROUTING �� mangle � �� , �� �� , �� �� , �� � ��. � �� , �� , �� ��.
7	nat	POSTROUTING	�� Source Network Address Translation. �� �� �� . �� �� , �� -�� DROP.
8	�	�	�� (��, eth0)
9	�	�	�� (�.�., Internet)

�� , ��
�� . ��
�� :

��
�� . � ��
�� (routing decision) ��
��, ��
INPUT, �� — � �� FORWARD.

�� , �� , � ��
�� , ��
�� (DNAT) � �� PREROUTING �� nat �
��
�� .
�� — �� ��
�� . �� DNAT � �� , ��
��, �� .

� �� rc.test-iptables.txt
��
�� .

3.2. �� Mangle

�� , �� ,
��
(mangle — ��, ��. ��. ��.). �.�. � ��
�� TOS (Type Of Service) � �.�.

�� , ��
�� ,
�� (DNAT, SNAT,
MASQUERADE).

� ��
�� :

TOS
TTL
MARK

�� TOS ��
Type of Service � ��. ��
��
��, �.�. �� . ��,
�� , ��
��
��. �� , ��
�� , �� , ��
��, �� , ��
�� .

�� TTL ��
�� TTL (Time To Live) ��. ��
�� . ��
�� , ��
�� (Internet Service
Providers). �� , ��
��
��. � �� TTL ��
�� , ��
«��» �� .

�� MARK ��
�� , ��
�� iptables �� , ��
iproute2. � ��
«��» �� ,
�� .�.

3.3. �� Nat

��
�� NAT (Network Address Translation). ��
�� , ��
�� , ��
��
��. �� :

DNAT
SNAT
MASQUERADE

�� DNAT (Destination Network Address
Translation) ��
�� . �� , ��
�� ,
�� .

SNAT (Source Network Address
Translation) ��
��. � ��
�� , � �� IP
��
��. � �� , � �� SNAT, ��
�� , ��
��
�� .

�� (MASQUERADE) ��
��, �� SNAT, �� ,
MASQUERADE ��
�� . �� , �� ,
�� — ��
�� IP ��
��, � �� SNAT IP ��
��. ��, �� , MASQUERADE ��
� �� IP ��, �.�. ��
��, �� PPP, SLIP �� DHCP.

3.4. �� Filter

�� , � ��
�� . ��
�� , �� (�� ACCEPT � DROP ��), � ��
�� . �� , ��
�� , ��
�� . � ��
�� , �� ,
�� , ��
�� .

�� 4. ��
��

� ��
�� (state machine). ��
� ��
��, � ��
�� .

4.1. ��

�� (state machine) ��
�� iptables � � ��
�� , ��
�� . ��
�� «��
��» (state machine). � ��
�� . ��
�� , �� netfilter ��
�� .
��
�� , ��
�� .

� �� iptables, �� 4-�
�� : NEW, ESTABLISHED, RELATED � INVALID. ��
�� . ��
��, �� , ��
—state.

��
�� — �� (conntrack). ��
��
�� , �� . � ��
��
��, �� , ��
��-��. ��
�� , �� TCP, UDP �� ICMP. ��
��
�� . �� — �� UDP ��
IP-�� .

� ��
��/�� .
��, ��
�� iptables/netfilter, �� . ��
� ��, ��
��
�� . ��
�� . �� ,
�� .

�� PREROUTING, �� , ��
�� , � ��
�� OUTPUT. �� , �� iptables
�� , ��
��, � �� . ��
�� , ��
�� OUTPUT ��
NEW, � ��
��, �� PREROUTING �� ESTABLISHED, � �� . ��
�� , �� NEW ��
�� PREROUTING. �� , ��
�� PREROUTING � OUTPUT �� nat.

4.2. ��
��

�� , ��
�� /proc/net/ip_conntrack. ��
�� . �� ip_conntrack ��, ��
cat /proc/net/ip_conntrak ��
�� , ��:

tcp  6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \
     dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 \
     dport=32775 use=2

� �� , ��
��, �� . ��, ��
�� — �� , � �� — tcp.
��
��. �� , ��
«�� » �� (�.�. ��
��, ��
�� ). �� , ��
�� 117 ��, ��
�� . ��
�� , ��
�� -��
��. �� 1 �� . ��
�� . ��
�� SYN_SENT. ��
�� .
�� SYN_SENT �� , ��
�� TCP SYN. ��
�� , �� .
�� [UNREPLIED], ��
��, �� .
� ��
��, �� IP �� /�� (�� ,
�� , ��
��), �� .

�� , ��
�� linux/include/netfilter-ipv4/ip_conntrack*.h.
�� -�� . ��
IP-�� — TCP, UDP �� ICMP ��
��-��, �� linux/include/netfilter-ipv4/ip_conntrack.h.
�� , ��
�� .

�� , � patch-o-matic, ��
tcp-window-tracking, ��
��
�� , �.�. ��
«�� ». ��
��
�� .

��
�� , �� /proc/sys/net/ipv4/netfilter.
�� /proc/sys/net/ipv4/netfilter/ip_ct_*.

�� [UNREPLIED] � ��
[ASSURED]. ��
��, ��
��
�� . �� ,
��
��-��, ��
ipsysctl � �� . �� 128 ��
�� 8192 ��, �� 256 �� — 16376. ��
��
�� /proc/sys/net/ipv4/ip_conntrack_max.

4.3. ��
��

�� , � �� , �
�� , ��
�� . ��, ��
�� 4 ��. � ��
�� —state. ��
�� NEW, ESTABLISHED, RELATED � INVALID. � ��, ��
��, �� .

�� 4-1. ��
��

��	��
NEW	�� NEW �� , �� �� . �� ��, �� , �� . �� �� SYN �� �� , �� NEW. ��, �� �� SYN �� �� NEW. �� �� , �� �� , �� �� «��» ��, «��» �� ��, �� , �� �� .
RELATED	�� RELATED �� «��». �� RELATED �� �� , �� ESTABLISHED. �� , �� RELATED ��, �� �� , �� ESTABLISHED. �� �� , �� �� RELATED, �� �� FTP-data, �� �� FTP control, � �� DCC ��, �� IRC. �� , �� TCP � �� UDP �� �� TCP �� UDP �� �� �� .
ESTABLISHED	�� ESTABLISHED �� , �� . �� �� ESTABLISHED �� �� . �� , �� , �� , �� �� ESTABLISHED �� �� �� (��). �� �� NEW �� RELATED�� ESTABLISHED.
INVALID	�� INVALID �� , �� �� �� . �� �� , �� �� ICMP-�� , �� ��. �� �� DROP � �� .

��
—state. ��
��
��. �� 1024,
�� , �� ,
�� , ��
�� , ��
«��» �� (��)
��, �� .

4.4. TCP ��

� ��
��
�� TCP, UDP � ICMP, � �� , ��
��
�� , ��, ��. ��
�� TCP, ��
��
�� iptables.

TCP ��
�� , ��
�� , ��
�� . �� SYN ��, � ��
�� SYN/ACK ��
�� ACK. ��
�� . ��
��: «� �� ?». �
�� .

�� , ��
�� . �� , ��
�� . �� ,
��, � �� , ��
�� . ��, ��
�� «��» �� (SYN) ��, ��
NEW. ��
�� (SYN/ACK), ��
�� ESTABLISHED. ��
��? �� . �� , ��
�� NEW � ESTABLISHED, � ��
�� ESTABLISHED � ��
��. � ��, ��
�� NEW, ��
�� «�� »,
�� NEW �� . �
�� , ��
�� TCP ��
��, �� . � ��
�� RFC 793 — Transmission Control
Protocol �� 21-23. ��
�� .

� ��
��, �� , ��
�� . ��
�� /proc/net/ip_conntrack. ��
�� SYN.

tcp      6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
     dport=1031 use=1

�� , ��
�� — �� SYN (�� SYN_SENT), ��
�� (�� [UNREPLIED]). ��
��-��, ��
��:

tcp      6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
     use=1

�� , �� SYN/ACK. ��
�� SYN_RECV. ��
� ��, �� SYN ��
�� -�� (SYN/ACK). �� , ��
�� «��» ��, ��
�� , �� [UNREPLIED]. � ��
�� ACK-��, � ��
��

tcp      6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
     sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
     sport=23 dport=1031 use=1

�� ESTABLISHED (��). ��
�� , � ��
�� [ASSURED] (��).

�� , TCP ��
�� .

�� , ��
�� ACK. �� — ��
�� . �� ,
�� , ��
�� RST (��). � ��
�� .

�� , �� TIME_WAIT, ��
�� -�� 2 ��, � ��
�� .
�� «�� »,
�� , «��»
�� (��).

�� RST, ��
CLOSE. ��
�� -��
�� 10 ��. �� RST ��
�� . ��
�� . � ��
��
�� .

�� 4-2. Internal states

��	��
NONE	30 ��
ESTABLISHED	5 ��
SYN_SENT	2 ��
SYN_RECV	60 ��
FIN_WAIT	2 ��
TIME_WAIT	2 ��
CLOSE	10 ��
CLOSE_WAIT	12 ��
LAST_ACK	30 ��
LISTEN>	2 ��

��
��, �� , ��
�� /proc (�� proc/sys/net/ipv4/netfilter/ip_ct_tcp_*).
�� , ��
3000 �� 30 ��.

�� , ��
��, ��
�� TCP ��. �� — ��
�� , �� NEW ��, ��
�� SYN.

��
�� (firewalling), ��
�� , � ��
�� .
�� NEW � ��
�� SYN ��
��. ��
�� tcp-window-tracking ��
patch-o-matic, ��
��
�� TCP window.

4.5. UDP ��

�� , UDP ��
��. �� , ��
�� , ��
�� , ��
�� — ��
�� . �� UDP, ��
�� . ��, ��
�� . ��
�� , ��
�� .

�� , �� UDP ��
�� TCP ��, � ��
�� . ��
�� , �� . ��
�� , �� UDP.

udp      17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \
     [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 \
     dport=137 use=1

��, �� — �� (udp) � ��
�� (��. /etc/protocols ��. ��.). �� —
�� «�� » �� . ��
�� , �� —
�� . �� ,
�� (�� [UNREPLIED]). � ��
�� .
�� 30 ��.

udp      17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 \
     dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 \
     dport=137 use=1

�� «��» ��
��, �� ESTABLISHED (��),
��
�� [UNRREPLIED] �, �� ,
�� 180 ��. ��
�� [ASSURED] (��
��), �� . �� [ASSURED] ��
��
��.

udp      17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 \
     dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 \
     dport=1025 [ASSURED] use=1

�� «��». ��
��
��, �� [ASSURED]. �� 180
�� , ��
�� . ��
�� , ��
��. «�� » ��
�� , ��
�� , ��
��
��.

4.6. ICMP ��

ICMP ��
��
��. ��, �� 4 �� ICMP ��, ��
�� , �� :
NEW � ESTABLISHED. � ��
�� ICMP Echo Request/Echo Reply, ICMP Timestamp Request/Timestamp
Reply, ICMP Information Request/Information
Reply � ICMP Address Mask Request/Address Mask
Reply. �� — ICMP Timestamp Request/Timestamp Reply
� ICMP Information Request/Information
Reply �� , � ��
��, �� (DROP). ��
��.

�� , �� Echo Request (��-��) � ��,
�� (��) �� NEW. ��
�� Echo Reply, � ��
�� ESTABLISHED. ��
�� (Echo Request) � ip_conntrack �� :

icmp     1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 \
     id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 \
     type=0 code=0 id=33029 use=1

�� , ��
�� TCP � UDP, ��
��
��, �� — type, code � id. �� type �� ICMP, �� code — �� ICMP. �� ICMP �� �� ICMP. � ��
id ��
��. �� ICMP-�� .
�� , � �� ICMP-�� , ��
�� , ��
��, ��
�� .

�� — �� [UNREPLIED], ��
�� . �� , �� .
�� .
�� . ��
�� ICMP ��, ��
�� ICMP Echo Reply. ��
��-�� , �� .

�� ESTABLISHED. ��, �� , ��
�� , ��
�� , ��
netfilter, �� .

� �� NEW, � �� ESTABLISHED.

�� , ��
�� (��
�� , ��, �� ) �
�� , ��
�� .

ICMP �� , ��-��, 30 ��. ��
��, � �� , �� . ��
�� /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout.
( ��, �� /proc/sys/net/ipv4/netfilter/ip_ct_*
��
«��» tcp-window-tracking �� patch-o-matic
��. ��.).

�� ICMP ��
�� , �� UDP �� TCP ��. ��
�� (RELATED) � ��
��. �� ICMP Host Unreachable �� ICMP Network Unreachable. ��
��
�� , � ��
�� ICMP ��, ��
�� RELATED. ��
�� .

� ��
�� (SYN ��). ��
NEW �� . ��, � ��
�� , �� , ��
�� ICMP Network Unreachable. ��
�� RELATED, ��
�� , ��
��, �� . ��
��, �� , ��
�� .

�� UDP �� — ��
�� . �� ICMP, �� UDP ��, ��
RELATED. ��
��.

�� UDP �� . ��
�� NEW. ��
(�� ), ��
�� ICMP Network Prohibited. ��
�� UDP ��, ��
�� RELATED � �� . ��
�� , � ��
�� .

4.7. ��
��-��

� ��
�� , ��, ��
�� . � ��
�� -�� . ��
��-�� , ��
�� NETBLT, MUX � EGP. �� -��
�� UDP ��. ��
�� NEW, � �� — ��
ESTABLISHED.

�� -��, ��
�� , ��
�� /proc/sys/net/ipv4/netfilter/ip_ct_generic_timeout.
��-�� 600 ��, �� 10 ��
� �� , �� ,
��
��.

4.8. ��
��

�� , ��
�� . �� ICQ, IRC � FTP. ��
��
��. ��
��
��.

� �� FTP. �� FTP ��
��, �� «��
FTP» (FTP control session). ��
�� , ��
�� . ��
�� . ��
�� FTP �� IP �� . ��
�� , ��
�� 20 (�� FTP-Data) � ��
�� .

�� , ��
�� , ��
�� . ��-��
��
��.

��
�� , �� ,
�� , ��
�� , �� . ��
�� , ��
��
�� RELATED, ��
�� . ��
�� .

�� FTP �� .
�� , � ��
�� IP ��
��. �� 20-� �� (FTP-data) � ��
�� . �� FTP ��
��, ��
�� , �� .
�� , ��
�� HTTP � FTP ��
�� . ��
�� FTP.

��
��. �� , ��
�� FTP � IRC. ��
�� , ��
�� patch-o-matic, ��
��
�� , �� ntalk �� H.323. �� ,
�� , �� : ��
�� CVS iptables, ��
�� patch-o-matic, ��
�� netfilter � �� — ��
�� . ��
�� , �� Rusty Russell’s Unreliable
Netfilter Hacking HOW-TO.

��
�� , ��
��. �� , ��
�� :

modprobe ip_conntrack_*

�� , ��
��
�� (NAT), ��
�� , ��
�� . ��, ��
�� FTP ��, ��
�� NAT. �� NAT �� ip_nat_, �
�� . � ��
�� ip_nat_ftp. �� IRC �� ip_nat_irc. ��
�� ,
��: ip_conntrack_ftp � ip_conntrack_irc.

�� 5. ��
��

� �� iptables ��
��, ��
�� . �� iptables-save � iptables-restore. ��
��, � �� /�� .
��
�� (shell), � ��
�� .

5.1. ��

�� iptables-save � iptables-restore ��
�� .
�� , ��
�� , ��
iptables ��
�� , ��,
�� , ��, ��
�� . ��
�� ,
�� .

�� iptables-save � iptables-restore �� iptables-save ��
�� . ��
iptables-restore ��
�� . ��
��, �� /��
�� . iptables-save «� ��
��» ��
�� , � iptables-restore ��
� ��
�� . �� — ��
��, ��
�� , � ��
�� , ��
�� , � ��
��, ��
�� .

�� , ��
�� , ��
�� . ��
�� , ��
�� .

5.2. � ��

� �� , �� iptables-restore ��
�� . �� —
�� . � ��
iptables-restore. ��
�� — �� , ��
�� IP-��
�� . ��
�� iptables-restore ��
��.

��
��, �� IP-��
�� (��, � �� sed) ��
��. �� , �
��
�� iptables-restore. ��
�� — ��
�� iptables-save ��
��, �� , ��
iptables-restore. �� —
�� .

�� — �� iptables-restore ��
��, � ��
�� . ��
��, �� . ��
�� , �� iptables-restore ��
�� IP-��
�� , ��
��
�.�..

�� iptables-restore � iptables-save � ��, ��
�� . ��
�� , �� , ��
��
��. ��, �� , ��
��, ��
�� . ��
�� , � ��
�� , ��
�� , ��
�� .

5.3. iptables-save

�� iptables-save, �� ,
�� ,
�� iptables-restore. ��
�� .

iptables-save [-c] [-t table]

�� -c (��
�� —counters) �� iptables-save ��
�� . ��
�� , ��
�� . ��-��, ��
�� -�, ��
��.

� �� -t (�� —table) ��
�� . �� -t �� , ��
��. �� iptables-save � ��, ��
�� .

# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
*filter
:INPUT ACCEPT [404:19766]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [530:43376]
COMMIT
# Completed on Wed Apr 24 10:19:17 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
*mangle
:PREROUTING ACCEPT [451:22060]
:INPUT ACCEPT [451:22060]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [594:47151]
:POSTROUTING ACCEPT [594:47151]
COMMIT
# Completed on Wed Apr 24 10:19:17 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [3:450]
:OUTPUT ACCEPT [3:450]
COMMIT
# Completed on Wed Apr 24 10:19:17 2002

��, �� #, �� .
�� * (��), ��:
*mangle. ��
�� . ��
�� :<chain-name>
<chain-policy>
[<packet-counter>:<byte-counter>], ��
<chain-name> — �� (�� PREROUTING), <chain-policy>
— �� -�� (�� ACCEPT). ��
�� , �� ,
�� iptables -L -v. ��
�� COMMIT, �� , ��
��
�� .

��
��, �� iptables-save. ��
�� (Iptables-save ruleset)
:

# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*filter
:INPUT DROP [1:229]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
[0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[0:0] -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
[0:0] -A FORWARD -i eth1 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
[0:0] -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Wed Apr 24 10:19:55 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*mangle
:PREROUTING ACCEPT [658:32445]
:INPUT ACCEPT [658:32445]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [891:68234]
:POSTROUTING ACCEPT [891:68234]
COMMIT
# Completed on Wed Apr 24 10:19:55 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*nat
:PREROUTING ACCEPT [1:229]
:POSTROUTING ACCEPT [3:450]
:OUTPUT ACCEPT [3:450]
[0:0] -A POSTROUTING -o eth0 -j SNAT --to-source 195.233.192.1
COMMIT
# Completed on Wed Apr 24 10:19:55 2002

�� -c — ��
�� , ��
�� . �� , ��
�� iptables-save ��
��, ��, ��
�� :

iptables-save -c >
/etc/iptables-save

�� , ��
��, � �� /etc/iptables-save.

5.4. iptables-restore

�� iptables-restore ��
�� (��) �� , ��
�� iptables-save. ��
��
�� . �� :

iptables-restore [-c] [-n]

�� -c (�� —counters) ��
�� .

�� -n (�� —noflush) �� iptables-restore � ��, ��
�� . ��-��
iptables-restore (�� -n) ��
�� .

�� iptables-restore ��
�� , �� :

cat /etc/iptables-save | iptables-restore
-c

� �� /etc/iptables-save ��
�� cat � ��
�� iptables-restore. ��
�� , � ��
�� , ��
�� , ��
�� .

��
�� . �� , ��
�� .

�� 6. ��

� ��
�� iptables. �� , ��
�� , ��
��. ��
(targets) � �� (�.�.
�� ).

6.1. ��

�� , �� — �� ,
�� , ��
�� , � ��, ��
�� . � ��
�� :

iptables [-t table] command [match]
[target/jump]

�� , �� (target/jump)
�� , ��, ��
��. �� , ��
�� .

�� [-t table], ��
�� filter, ��
�� , �� .
��
�� , ��
�� .

��, �� , ��
��. �� , ��
�� . �� iptables,
��: �� , ��
��, �� .�.

�� match �� , ��
��
�� . �� —
IP-�� , IP-��
��,��, ��, �� .�.
�� , �� —
�� .

� �� target ��, ��
�� . ��
�� ,
«��» �� , ��
�� .�.

6.2. ��

�� -t ��
��. �� filter. � �� -t �� .

�� 6-1. ��

��	��
nat	�� nat �� �� (Network Address Translation). �� ��. �� �� . �� ��, �� ��-�� . �� PREROUTING �� �� . �� OUTPUT �� �� , �� �� , �� �� . � �� �� — POSTROUTING, �� �� �� .
mangle	�� �� . �� �� TTL, TOS �� MARK. ��: � �� MARK �� , �� �� , �� �� ��, �� �� (� �� ) �� . �� �� PREROUTING, POSTROUTING, INPUT, OUTPUT � FORWARD. PREROUTING �� �� , �� �� . POSTROUTING �� �� , �� �� . INPUT — �� �� �� . OUTPUT — �� �� , �� ��. FORWARD — �� �� �� , �� �� . ��, �� mangle �� �� �� (Network Address Translation, Masquerading), �� �� nat.
filter	�� filter �� �� . �� , �� �� DROP, LOG, ACCEPT �� REJECT �� ��, �� . �� . �� — FORWARD, �� �� , �� ��. �� INPUT �� , �� �� (��). � �� OUTPUT — �� �� , �� �� .

��
��. ��
��, � �� . ��
�� ,
�� . ��, � ��
��, �� .

6.3. ��

�� .
�� iptables ��
��. �� —
��
�� . ��
�� , �� iptables.

�� 6-2. ��

��	-A, —append
��	iptables -A INPUT …
��	�� �� .
��	-D, —delete
��	iptables -D INPUT —dport 80 -j DROP, iptables -D INPUT 1
��	�� . �� �� , �� — �� �� -D (��. �� ), �� — �� . �� �� , �� , �� �� , �� ��, �� . �� 1.
��	-R, —replace
��	iptables -R INPUT 1 -s 192.168.0.1 -j DROP
��	�� ��. � �� �� .
��	-I, —insert
��	iptables -I INPUT 1 —dport 80 -j ACCEPT
��	�� . ��, �� ��, �� , �� ��. � �� , ��, �� �� 1-� � �� INPUT.
��	-L, —list
��	iptables -L INPUT
��	�� , � �� �� INPUT. �� ��, �� ��. �� �� , �� -n, -v, � ��.
��	-F, —flush
��	iptables -F INPUT
��	�� (��) �� �� (��). �� �� , �� , �� �� . (�� , �� �� -t (—table), �� �� filter, ��. ��. )
��	-Z, —zero
��	iptables -Z INPUT
��	�� ��. �� , �� �� . �� -v �� -L, �� �� , �� �� . �� �� -L � -Z. � �� �� , � �� �� .
��	-N, —new-chain
��	iptables -N allowed
��	�� �� �� allowed. �� �� �� (�� �� DROP, REJECT � �.�.)
��	-X, —delete-chain
��	iptables -X allowed
��	�� ��. �� �� ��. �� , �� �� ��.
��	-P, —policy
��	iptables -P INPUT DROP
��	�� -�� �� . �� -�� ��, �� �� . � �� �� DROP � ACCEPT.
��	-E, —rename-chain
��	iptables -E allowed disallowed
��	�� -E �� �� . � �� allowed �� �� disallowed. �� �� , � �� �� .

�� . ��
�� iptables -h ��, �� ,
iptables —help. ��
�� .
��
�� . �� , ��
�� , ��
�� (matches) �� (targets). ��
�� .

�� 6-3. �� 

��	-v, —verbose
��, � ��	—list, —append, —insert, —delete, —replace
��	�� �� , �� , �� �� —list. � �� �� —list, � �� �� , �� �� . �� �� �� K (x1000), M (x1,000,000) � G (x1,000,000,000). �� , �� —list �� �� (�� ) �� �� -x, �� . �� -v, —verbose �� �� —append, —insert, —delete �� —replace, �� �� .
��	-x, —exact
��, � ��	—list
��	�� �� �� K, M, G. �� �� —list � �� �� .
��	-n, —numeric
��, � ��	—list
��	�� iptables �� IP-�� � �� �� . �� �� —list.
��	—line-numbers
��, � ��	—list
��	�� —line-numbers �� �� �� —list. �� �� . �� �� —list.
��	-c, —set-counters
��, � ��	—insert, —append, —replace
��	�� �� �� . ��, �� —set-counters 20 4000 �� �� = 20, � �� = 4000.
��	—modprobe
��, � ��	��
��	�� —modprobe �� �� . �� �� , �� �� (search path). �� �� .

6.4. ��

��
��. � �� . �� — ��  ��
�� . �� — TCP �� ��
�� TCP ��. �� — UDP �� ��
�� UDP ��. �� — ICMP �� �� ICMP ��. � �� —
�� , �� state, owner, limit � ��.

6.4.1. ��

�� �� . ��
�� , ��
�� . �
�� —protocol �� , ��
��
��. ��, �� TCP ��, ��
�� —protocol ��
�� — TCP.
�� —protocol ��
��, ��
��.

�� 6-4. �� 

��	-p, —protocol
��	iptables -A INPUT -p tcp
��	�� �� . �� �� TCP, UDP � ICMP. �� �� /etc/protocols. �� ��, � �� �� ��, � �� ALL. � �� �� — �� ��, �� , �� ICMP �� 1, TCP — 6 � UDP — 17. �� �� /etc/protocols, �� ��. �� ��, �� , �� : udp,tcp (�� �� , �� �� ! ��, man iptables �� ��, �� �� . �� �� patch-o-matic? ��. ��.) �� �� 0, �� �� ALL, �� , �� �� —protocol �� ��. �� , �� (�� ) �� !, �� —protocol ! tcp �� , UDP � ICMP.
��	-s, —src, —source
��	iptables -A INPUT -s 192.168.1.1
��	IP-��(�) �� . �� �� , �� ��, �� IP-��. � �� address/mask, �� 192.168.0.0/255.255.255.0, �� 192.168.0.0/24, �.�. �� , �� !, �� , �� �� , �.�. —source ! 192.168.0.0/24 �� 192.168.0.x.
��	-d, —dst, —destination
��	iptables -A INPUT -d 192.168.1.1
��	IP-��(�) ��. �� �� —source, �� ��, �� . �� IP-��, �� . �� ! �� .
��	-i, —in-interface
��	iptables -A INPUT -i eth0
��	��, � �� ��. �� �� INPUT, FORWARD � PREROUTING, � �� �� . �� �� ��, �� -i +. �� , �� ! �� . �� �� +, �� ��, �� , �� -i PPP+ �� PPP ��, � �� -i ! eth+ — �� ��, �� eth.
��	-o, —out-interface
��	iptables -A FORWARD -o eth0
��	�� . �� �� OUTPUT, FORWARD � POSTROUTING, � �� �� . �� ��, �� -o +. �� , �� ! �� . �� �� +, �� ��, �� , �� -o eth+ �� eth ��, � �� -o ! eth+ — �� ��, �� eth.
��	-f, —fragment
��	iptables -A INPUT -f
��	�� �� , �� , �� , �� ��/�� , � �� ICMP-�� . � �� �� �� , �� �� . �� , �� ! �� �� . �� ! �� -f, �� ! -f. �� �� «�� �� /�� ��, �� �� ».

6.4.2. ��

� �� �� , ��, ��
��, ��
��, �� —protocol tcp. ��
�� ,
�� TCP ��, UDP �� � ICMP �� (��
� �� -m tcp, �.�. � ��
�� , ��
�� , �� -�� — ��
�� . ��. ��.). ��
��
�� -m, -match, �� -m tcp.

6.4.2.1. TCP ��

��
�� TCP ��. ��
��, ��
—protocol tcp. ��: ��
—protocol tcp ��
�� . ��
�� tcp ��, �� udp � icmp ��. (� ��
�� ��. ��.).

�� 6-5. TCP ��

��	—sport, —source-port
��	iptables -A INPUT -p tcp —sport 22
��	�� , � �� �� . � �� �� ��. �� �� /etc/services. �� �� . �� �� . �� �� �� , �� ��, �� �� . �� �� ��, �� —source-port 22:80. �� , �.�. �� �� —source-port :80, �� �� 0. �� , �.�. �� �� —source-port 22:, �� �� 65535. �� —source-port 80:22, � �� iptables �� 22 � 80 ��, �.�. �� �� —source-port 22:80. �� , �� ! �� ��. �� —source-port ! 22 �� , �� 22. �� �� , �� —source-port ! 22:80. �� �� multiport.
��	—dport, —destination-port
��	iptables -A INPUT -p tcp —dport 22
��	�� , �� �� . �� �� , �� —source-port.
��	—tcp-flags
��	iptables -p tcp —tcp-flags SYN,FIN,ACK SYN
��	�� tcp-��. �� ��, �� �� �� . �� �� SYN ��, � �� FIN � ACK ��. � �� �� SYN, ACK, FIN, RST, URG, PSH, � �� �� ALL � NONE. ALL — �� �� �� NONE — �� . ��, �� —tcp-flags ALL NONE �� — «�� �� ». �� , �� ! �� �� : �� �� , �� �� .
��	—syn
��	iptables -p tcp —syn
��	�� —syn �� ��, �� ipchains. �� �� SYN � �� ACK � FIN. �� �� —tcp-flags SYN,ACK,FIN SYN. �� �� TCP. �� ��, �� �� , �� �� ��. �� , �� �� !. �� ! —syn �� — «�� , �� �� », �.�. �� �� FIN �� ACK.
��	—tcp-option
��	iptables -p tcp —tcp-option 16
��	�� �� , TCP �� �� . TCP Option — �� �� . �� 3 �� ��. �� 8-�� �� , �� ��. �� 8-�� �� . �� ��, �� �� , ��, �� �� , �� �� ��, �� (�� ). ��, �� TCP ��, �� �� TCP ��. �� ��, �� �� !. �� �� TCP Options �� �� Internet Engineering Task Force

6.4.2.2. UDP ��

� �� ,
�� UDP. ��
�� —protocol udp. �� ,
�� UDP ��
�� , � ��
��
��. �� UDP ��
�� . �� ,
�� (�� ICMP �� ). ��
��
�� , � �� TCP ��. ��: ��
�� , UDP �� ICMP, ��
�� , �� TCP ��. ��
��, � �� .

�� 6-6. UDP ��

��	—sport, —source-port
��	iptables -A INPUT -p udp —sport 53
��	�� , � �� �� . � �� �� ��. �� �� other/services.txt. �� �� �� . �� �� . �� �� �� , �� ��, �� �� . �� �� ��, �� -source-port 22:80. �� , �.�. �� �� —source-port :80, �� �� 0. �� , �.�. �� �� —source-port 22: , �� � �� 65535. �� —source-port 80:22 , � �� iptables �� 22 � 80 ��, �.�. �� �� —source-port 22:80 . �� , �� ! �� ��. �� —source-port ! 22 �� , �� 22. �� �� , �� —source-port ! 22:80.
��	—dport, —destination-port
��	iptables -A INPUT -p udp —dport 53
��	��, �� . �� � �� —source-port.

6.4.2.3. ICMP ��

�� , �� , ��
�� . ��
�� IP ��, ��
��, ��
�� . �� ICMP �� IP ��, �� .
��
��, �� , ��
��. ��, ��
�� , �� ICMP host unreachable. ��
�� ICMP ��, ��
�� �� ICMP. ��
�� ICMP ��. ��
�� , ��
—protocol icmp. ��, ��
�� ICMP ��
�� , ��
�� .

�� 6-7. ICMP ��

��	—icmp-type
��	iptables -A INPUT -p icmp —icmp-type 8
��	�� ICMP �� �� . �� RFC 792. �� ICMP �� �� iptables —protocol icmp —help, �� �� ICMP. �� ��, �� ! �� , �� —icmp-type ! 8.

6.4.3. ��

�� , ��
�� , � �� -m �� —match. ��, ��, ��
�� state, ��
�� : -m state ��
��. ��
�� , � �� ,
��, � �� , ��
��. ��
�� , �� ,
� �� .

6.4.3.1. �� Limit

�� -m limit. ��
�� , ��
(logging) � �.�. �� , ��
�� ,
�� . ��
�� ! �� , ��
-m limit ! —limit 5/s. � ��
�� , ��
�� .

��
�� , ��
��
�� (�.�. �� «��»). ��
«��» ��
—limit. �� —limit-burst ��
«�� ». � ��
�� —limit 3/minute —limit-burst
5, �� 5 �� (��
�� ), ��
«��» � ��
�� «��» ��, �.�.
«��» ��. �� 20 ��
«��» � �� (�
�� —limit), ��
�� , ��
«��» ��, �.�. ��
��.

�� .

�� , ��
-m limit —limit 5/second —limit-burst 10. ��
limit-burst �� «��»
�� 10-��. �� , ��
�� , �� .
��, � �� 1/1000 ��, �� 10
��, ��
«��» � «��» ��
��: 1-2-3-4-5-6-7-8-9-10.
�� . �� , ��
�� , ��
�� «��» (��
��), �� (��) ��
��, �� ,
�� -��.
�� 1/5 �� «��» �
�� 1, � ��
��, �� «��» �� .
�� , �� 10-��
«��» �� 5
��.
�� , �� «��» �
«��» �� 1 � ��
�� .

�� : ��
�� limit ��
��, �� (��
�� ) ��
��. �� :

�� -m limit ��
�� —limit � —limit-burst. ��
�� , ��
��-��.
�� —limit-burst — ��
�� , ��
�� .
�� —limit — �� , �
�� burst limit «��
��».

��, ��
C � ��
��-��.

�� 6-8. ��
limit

��	—limit
��	iptables -A INPUT -m limit —limit 3/hour
��	�� «�� » �� ��. � �� �� . �� �� : /second /minute /hour /day. �� �� 3 �� , �� 3/hour. �� �� ! � �� ��.
��	—limit-burst
��	iptables -A INPUT -m limit —limit-burst 5
��	�� �� burst limit �� limit. �� �� , �� , � �� �� (�� —limit) �� �� . �� ��, �� burst limit �� �� , �� —limit-burst. �� �� ��, �� —limit. �� ��-�� 5. �� �� �� Limit-match.txt � �� �� limit, �� ping-�� ��.

6.4.3.2. �� MAC

MAC (Ethernet Media Access Control)
�� MAC-��
��. �� -m mac, �� ,
�� , ��
�� .

��
�� -m mac. ��
�� , �� , �� ,
��, �� .

�� 6-9. �� MAC

��	—mac-source
��	iptables -A INPUT -m mac —mac-source 00:00:00:00:00:01
��	MAC �� , �� . MAC �� �� XX:XX:XX:XX:XX:XX. �� ��, �� ! �� �� , �� —mac-source ! 00:00:00:00:00:01, �� — «�� , �� , �� �� MAC �� 00:00:00:00:00:01» . �� �� PREROUTING, FORWARD � INPUT � �� .

6.4.3.3. �� Mark

�� mark ��
«��» �� . Mark — �� ,
��
� �� . ��
�� , ��, ��
��. ��
�� Linux — ��
�� MARK. �� mark ��
�� 0 �� 4294967296
�� 32-�� .

�� 6-10. ��
Mark

��	—mark
��	iptables -t mangle -A INPUT -m mark —mark 1
��	�� ��, �� «��». �� �� MARK, �� �� . �� , �� netfilter �� mark. ��, �� �� �� . �� mark �� ��, �� 4294967296 �� . �� �� . � �� �� : —mark 1/1. �� �� , �� AND �� .

6.4.3.4. ��
Multiport

�� multiport ��
�� .

��
�� -m multiport (��
—sport 1024:63353 -m multiport
—dport 21,23,80) ��. ��
�� iptables.

�� 6-11. ��
Multiport

��	—source-port
��	iptables -A INPUT -p tcp -m multiport —source-port 22,53,80,110
��	�� �� . � �� �� 15 �� . �� �� ��, �� . �� �� � �� -p tcp �� -p udp. �� �� �� —source-port.
��	—destination-port
��	iptables -A INPUT -p tcp -m multiport —destination-port 22,53,80,110
��	�� ��. �� �� -m multiport —source-port.
��	—port
��	iptables -A INPUT -p tcp -m multiport —port 22,53,80,110
��	�� �� . �� �� —source-port � —destination-port. �� �� , �.�. �� �� -m multiport —port 80, �� , �� �� 80 �� 80.

6.4.3.5. �� Owner

�� owner ��
�� «��» ��. ��
��
�� iptables. ��
�� OUTPUT. ��
��, ��
�� «��» �� .
�� , ��
�� «��» �
�� . � ��
ICMP responses. ��
�� ICMP responses ��.

�� 6-12. ��
Owner

��	—uid-owner
��	iptables -A OUTPUT -m owner —uid-owner 500
��	�� «��» �� User ID (UID). �� , � ��, �� �� .
��	—gid-owner
��	iptables -A OUTPUT -m owner —gid-owner 0
��	�� «��» �� Group ID (GID).
��	—pid-owner
��	iptables -A OUTPUT -m owner —pid-owner 78
��	�� «��» �� Process ID (PID). �� �� , ��, �� �� HTTP �� �� , �� �� , �� PID �� (�� �� ps) � �� PID � ��. �� �� Pid-owner.txt.
��	—sid-owner
��	iptables -A OUTPUT -m owner —sid-owner 100
��	�� Session ID ��. �� SID �� �� «��», ��, ��, �� HTTPD �� SID (�� �� HTTPD Apache � Roxen). �� Sid-owner.txt. �� �� HTTPD, � � �� �� — �� «��» ��, �� OUTPUT � �� ��.

6.4.3.6. �� State

�� state ��
��
�� , ��
�� , ��
�� ICMP � UDP. ��
�� , � �� -m state. ��
��
��
�� .

�� 6-13. ��
State

��	—state
��	iptables -A INPUT -m state —state RELATED,ESTABLISHED
��	�� �� (state) �� �� 4 ��: INVALID, ESTABLISHED, NEW � RELATED. INVALID ��, �� �� , �� �� . �� ESTABLISHED �� �� , �� �� ��. �� NEW ��, �� �� �� . � ��, �� RELATED �� �� ��, �� �� �� FTP, �� ICMP �� , �� �� TCP �� UDP ��. ��, �� NEW �� , �� SYN � �� TCP, �� �� , �, �� ��, �� , �� ��. �� �� ��.

6.4.3.7. �� TOS

�� TOS ��
�� TOS. TOS — Type Of Service —
�� 8-�� , ��
IP-��. �� , �� -m tos.

�� : ��
�� TOS, �� ,
��
��.

�� .
�� , ��
��
�� TOS. �� TOS �� . � ��
�� ,
�� . ��
�� :

�� 
�� , ��
�� , �.�., �� , ��
��
�� . ��, ��
�� , ��
��
��.

��
�� , ��
��
��. �� , ��
��
��.

�� 
��
�� . ��
�� PPP � SLIP ��, ��
�� , � ��, �� X.25, ��,
��
� �� .

��  ��
� ��, �� (� ��
��) �� . ��, ��
�� (�� ) ��
�� , ��
��. ��
��, �� «��»
��.

��  � ��
�� TOS ��. ��
�� .

�� 6-14. ��
TOS

��	—tos
��	iptables -A INPUT -p tcp -m tos —tos 0x16
��	�� �� TOS, �� ��. �� ��, �� � �� «��» �� �� iproute2 � �� �� linux. � �� �� �� , �� �� , �� �� iptables -m tos -h. �� . Minimize-Delay 16 (0x10) (�� ), Maximize-Throughput 8 (0x08) (�� ��), Maximize-Reliability 4 (0x04) (�� ), Minimize-Cost 2 (0x02) (�� ), Normal-Service 0 (0x00) (�� )

6.4.3.8. �� TTL

TTL (Time To Live) ��
�� IP ��. ��
��, �� 1. ��
�� , ��
�� ICMP �� 11 � �� 0
(TTL equals 0 during transit) ��
� �� 1 (TTL equals 0 during reassembly) .
��
�� -m ttl.

�� : ��
��
�� , �� iptables
1.2.6a, � �� , ��
�� TTL, �� -m ttl —ttl-eq ��, -m ttl —ttl-lt �� � -m ttl —ttl-gt ��.
�� .
�� , � ��
��:

�� 6-15. ��
TTL

��	—ttl
��	iptables -A OUTPUT -m ttl —ttl 60
��	�� TTL �� ��. �� �� , ��: �� ��, �� �� , �� �� «��» � ��. ��, �� �� . �� : �� �� �� TCP/IP �� �� .

6.4.4. �� «��»
(Unclean match)

�� unclean ��
��
��. �� , ��
��
�� . ��
�� , ��
��, ��
�� ., ��
��
�� .

6.5. ��

�� , ��
��, �� . ��
�� ACCEPT � DROP. ��, ��
�� .

��
�� , �.�. �� -j � ��
��, �� . ��
�� , �� — ��, ��
�� , �� , ��
� ��, �� , �� —
�� , ��
�� . ��,
�� tcp_packets � �� filter �
��

iptables -N tcp_packets

��
��:

iptables -A INPUT -p tcp -j tcp_packets

�.�. �� tcp, iptables ��
�� tcp_packets � ��
�� . ��
�� (� ��
�� INPUT) � ��
�� , �� , ��
��. ��
�� ACCEPT, ��
��
�� . ��
�� .
��
��
��.

�� — �� , ��
��, �� , ��
�� . ��, ��
DROP �� ACCEPT � ��, � ��
�� . �� , ��
�� . � ��
�� , �� ,
�� DROP � ACCEPT, � �� , ��
�� , �� , ��,
LOG, � ��
�� , �� DNAT � SNAT, TTL � TOS, ��
�� .

6.5.1. �� ACCEPT

�� . ��
�� ACCEPT, ��
�� (� �� , ��
�� ) � �� (��
�� ), �� , ��
�� .
�� -j ACCEPT.

6.5.2. �� DNAT

DNAT (Destination Network Address
Translation) ��
�� IP �� . ��
�� , �� DNAT, �� , � ��
�� , ��
��
��, �� . �� , �
��, ��
� �� web-��, �� , � ��
�� IP ��. �� ,
�� , �� HTTP ��
DNAT ��
�� web-��. ��
�� , ��
�� .

�� DNAT ��
�� PREROUTING � OUTPUT �� nat, � ��
�� -��. �� , ��
��, �� DNAT ��
�� , �� PREROUTING � OUTPUT.

�� 6-16. �� DNAT

��	—to-destination
��	iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 —dport 80 -j DNAT —to-destination 192.168.1.1-192.168.1.10
��	�� —to-destination ��, �� IP �� �� . � �� �� , �� �� 15.45.23.67, �� �� 192.168.1.1 �� 192.168.1.10. �� , �� �� �� , � �� �� �� . �� �� IP ��. �� �� , �� (��) �� . �� ip �� , �� —to-destination 192.168.1.1:80, � �� �� : —to-destination 192.168.1.1:80-100. �� , �� DNAT � SNAT �� . �� ��, �� �� TCP �� UDP, �� �� —protocol � ��.

�� DNAT ��
�� .
�� . � �� WEB ��
�� . ��
�� IP ��, � WEB-��
��. �� IP �� $INET_IP �� ,
HTTP �� $HTTP_IP �, ��
�� $LAN_IP. ��
�� PREROUTING �� nat:

iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP

� �� , �� , ��
�� 80-� �� $INET_IP ��
�� WEB-��. �� WEB-��
�� , �� . ��
��, ��
��? �� . ��
�� , ��
WEB-��. ��
�� $EXT_BOX.

�� $EXT_BOX � ��
$INET_IP
�� .
��, � ��
��, ��
��, � �� .
�� $HTTP_IP.
�� HTTP ��
�� , ��
�� $EXT_BOX. �� , ��
�� -�� HTTP ��.
��
��, �� , ��
�� .
�� $EXT_BOX.

� �� , �� , ��
�� , �� .
��
�� $LAN_BOX.

�� $LAN_BOX.
�� .
�� , ��
�� , �.�. ��
�� .
�� HTTP
��.
HTTP ��, ��
��, ��, ��
�� (�� IP
��, �� ) �
�� $LAN_BOX.
�� $LAN_BOX. ��
«��», ��
��, �� . ��
«��» ��
«��» ��.

�� SNAT. �� ,
�� . �� HTTP
�� , ��
�� .

iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IP

��, �� POSTROUTING ��
��
�� DNAT, ��
�� $HTTP_IP.

�� , �� , ��
��! �� , ��
�� . ��, � ��,
�� 80
�� , � �� $HTTP_IP. ��
��, �� :

iptables -t nat -A OUTPUT --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP

�� , � �� WEB-��,
�� .

�� , ��
��
�� . � ��
��
�� FORWARD �� filter. ��
�� , ��
PREROUTING � ��
�� DNAT.

6.5.3. �� DROP

�� «��» ��
iptables «��» � �� .
«��» ��
��, �.�. �� , ��
�� ACCEPT. �� , ��
�� ,
�� «��»
�� , �� ,
��
REJECT ��
�� .

6.5.4. �� LOG

LOG — ��, ��
�� . � ��
�� IP ��
�� . ��
�� dmesg �� syslogd ��
��. �� .
��
DROP ��
LOG, �� ,
�� . ��
�� ULOG, ��
�� , ��
��
��, � � �� MySQL � �.�..

�� — ��
� �� , ��
iptables �� netfilter, � syslogd. ��
�� syslogd �� man syslog.conf.

�� LOG �� , ��
�� .

�� 6-17. �� LOG

��	—log-level
��	iptables -A FORWARD -p tcp -j LOG —log-level debug
��	�� �� (log level). �� �� (man) �� syslog.conf. ��, �� : debug, info, notice, warning, warn, err, error, crit, alert, emerg � panic. �� error �� , �� err, warn — warning � panic — emerg. ��: � �� �� error, warn � panic. �� �� ��. �� ��. �� kern.=info /var/log/iptables � �� syslog.conf, �� �� iptables, �� �� info, �� �� /var/log/iptables ��, � �� � �� , �� ��, �� info. �� �� syslog � syslog.conf � �� �� manpages � HOWTO.
��	—log-prefix
��	iptables -A INPUT -p tcp -j LOG —log-prefix «INPUT packets»
��	�� (��), �� �� iptables. �� �� , � ��, � �� grep. �� �� 29 ��, �� .
��	—log-tcp-sequence
��	iptables -A INPUT -p tcp -j LOG —log-tcp-sequence
��	�� �� TCP Sequence ��. �� TCP Sequence �� �� «��» ��. �� �� , �� �� «�� » �� ��. �� , �� iptables.
��	—log-tcp-options
��	iptables -A FORWARD -p tcp -j LOG —log-tcp-options
��	�� �� TCP ��. �� �� . �� ��, �� LOG.
��	—log-ip-options
��	iptables -A FORWARD -p tcp -j LOG —log-ip-options
��	�� �� IP ��. �� —log-tcp-options, �� �� IP ��.

6.5.5. �� MARK

��
��. ��
�� mangle. ��
��
��, �� .�.. ��
�� Linux Advanced Routing and Traffic
Control HOW-TO. �� , ��
«��» ��
�� , �.�. ��
�� . �� -�� , ��
�� , ��
�� TOS.

�� 6-18. �� MARK

��	—set-mark
��	iptables -t mangle -A PREROUTING -p tcp —dport 22 -j MARK —set-mark 2
��	�� —set-mark �� �� . �� —set-mark �� �� .

6.5.6. ��
MASQUERADE

�� (MASQUERADE) � ��
�� , �� SNAT ��
—to-source. �� ,
�� , ��, � dialup
�� DHCP, �.�. � �� , �� IP ��
�� . ��
�� , ��
��, �� IP ��, ��
��
SNAT.

�� IP ��
�� , �� ,
�� —to-source � �� SNAT. �� MASQUERADE ��
— «��» ��
��. � �� SNAT, � �� , � ��
�� , �
�� , ��
��. �� «��» �� , ��
�� IP
��, ��
�� IP ��, ��
�� , � ��
�� .

�� , �� MASQUERADE ��
�� SNAT, ��
�� IP ��, ��, ��
��, ��
�� , ��
��.

�� MASQUERADE ��
�� POSTROUTING �� nat, ��
� �� SNAT. MASQUERADE �� ,
�� , �� .

�� 6-19. �� MASQUERADE

��	—to-ports
��	iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE —to-ports 1024-31000
��	�� —to-ports �� �� �� . �� , ��: —to-ports 1025, �� �� : —to-ports 1024-3000. �� , �� �� TCP �� UDP � �� —protocol.

6.5.7. �� MIRROR

�� MIRROR ��
�� ,
��
«��» ��
«�� ». � ��
MIRROR � ��, �� source �
destination �� (invert the source and
destination fields) � �� .
��
��, ��, �� ,
�� «��»
�� !

��
�� INPUT, FORWARD � PREROUTING, � � ��, ��
�� . ��, �� MIRROR ��
��, �� NAT, ��
«��» � �� . ��
�� , �� . ��, �
��, ��, �� , ��
MIRROR �� , �
TTL �� 255, ��
��
«��» ��. ��
«��» �� , � ��
«��» � «��» �� 1
�� (hop) �� 255 ��.
�� , ��, �� 1500 ��,
�� 380 �� !

6.5.8. �� QUEUE

�� QUEUE ��
�� . ��
�� , ��
�� .

�� : ��
�� , ��
�� ., ��, ��
�� , �� http://antonio.mccinet.ru/protection/iptables_howto.html
� �� aka virii5,
eugene@kriljon.ru

«…��
��, �� :

«queue handler» —
�� , ��
��
��; �
��
�� , �� , � ��
��.

�� IPv4 —
�� ip-queue, ��
�� . �� , ��
�� iptables ��
�� :

# modprobe iptable_filter
# modprobe ip_queue
# iptables -A OUTPUT -p icmp -j QUEUE

� �� , ��
�� ICMP �� (��, ��
�� ping) �� ip_queue, ��
�� . ��
�� , �� .
��
��, �� libipq API. ��
�� iptables. �� testsuite tools
(�� redirect.c) �� CVS. �� ip_queue ��
�� : /proc/net/ip_queue ��
�� (�� , ��
�� )
�� :
/proc/sys/net/ipv4/ip_queue_maxlen �� —
�� 1024. ��
�� , �� , ��
�� . ��
��, �� TCP ��
�� , � ��
�� (�� , ��
�� , ��. ��.). ��, ��
�� , ��
��
��, ��
��…»

6.5.9. �� REDIRECT

��
�� . � ��, �� ,
�� HTTP �� HTTP proxy.
�� REDIRECT ��
�� «��» ��
(transparent proxying), ��
�� .

REDIRECT ��
�� PREROUTING � OUTPUT �� nat. � ��
�� , ��
��. �� REDIRECT ��
��.

�� 6-20. �� REDIRECT

��	—to-ports
��	iptables -t nat -A PREROUTING -p tcp —dport 80 -j REDIRECT —to-ports 8080
��	�� —to-ports �� �� . �� �� —to-ports, �� , �.�. �� �� , �� . � ��, �� , —to-ports 8080 �� �� . �� ��, �� —to-ports 8080-8090. �� , �� �� TCP �� UDP � �� —protocol.

6.5.10. �� REJECT

REJECT ��, �� ,
� �� , �� DROP, �� DROP, �� REJECT ��
�� , �� . �� REJECT ��
�� INPUT, FORWARD � OUTPUT (� ��
��). �� ,
�� REJECT.

�� 6-21. �� REJECT

��	—reject-with
��	iptables -A FORWARD -p TCP —dport 22 -j REJECT —reject-with tcp-reset
��	��, �� �� , �� ��. �� REJECT � ��, �� �� -�� , � �� «��». �� : icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited � icmp-host-prohibited. ��-�� port-unreachable. �� �� ICMP error messages. �� ICMP �� �� �� ICMP. � �� — tcp-reset, �� �� TCP. �� �� tcp-reset, �� REJECT �� �� TCP RST, �� TCP RST �� �� TCP ��. �� �� RFC 793 — Transmission Control Protocol. (�� ICMP �� �� iptables -j REJECT -h ��. ��.).

6.5.11. �� RETURN

�� RETURN ��
��
��, �� , ��, ��
�� (�� INPUT), ��
�� -��. ��, � ��
��-�� ACCEPT �� DROP .

�� , ��, �� INPUT � �� , ��
�� — —jump EXAMPLE_CHAIN. ��, �
�� EXAMPLE_CHAIN �� , ��
�� —jump RETURN. ��
�� INPUT. �� , ��
�� , �� —jump RETURN � �� INPUT. ��
�� -�� INPUT.

6.5.12. �� SNAT

SNAT ��
�� (Source Network Address
Translation), �.�. �� IP �� IP
�� . ��, ��
��
�� , �� IP ��. ��
��. �� (forwarding) �
�� , ��
�� IP ��
��. � ��, ��
�� , �� , ��
� �� .

SNAT ��
� �� nat, � �� POSTROUTING. �� , ��
�� . ��
��
�� , �� , ��
��, ��
�� .

�� 6-22. �� SNAT

��	—to-source
��	iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT —to-source 194.236.50.155-194.236.50.160:1024-32000
��	�� —to-source �� �� , �� . �� ��, �� IP ��, �� �� ��. �� �� , �� �� , �� �� , ��: 194.236.50.155-194.236.50.160. ��, �� IP �� �� . �� �� , �� �� SNAT. �� �� ��. iptables ��, ��-��, �� , �� �� , � �� . �� , �� �� 512 �� 0-511, �� �� 512-1023 �� 512-1023, �, �� 1024-65535 �� 1024-65535. �� �� , �� ��.

6.5.13. �� TOS

�� TOS ��
�� Type of Service IP ��. ��
TOS �� 8 ��, ��
��. �� , �� iproute2. �� ,
��
�� .
�� , �� , � �� MARK, ��
�� , � ��
�� . �� , ��
�� ,
�� , �� . ��
�� , ��
��
��, ��, ��
�� WAN �� LAN.

�� TOS ��
�� ,
�� linux/ip.h. ��
��
�� TOS, ��
«��» FTOS � �� Paksecured Linux Kernel
patches, �� Matthew G. Marsh.
��, ��
«��». ��
�� TOS ��
��.

��
�� mangle.

� �� iptables (1.2.2 �
��) �� (��
�� ), � ��
� ��
�� .

�� TOS �� ,
�� .

�� 6-23. �� TOS

��	—set-tos
��	iptables -t mangle -A PREROUTING -p TCP —dport 22 -j TOS —set-tos 0x10
��	�� —set-tos �� �� �� . �� TOS �� 8-��, �� 0 �� 255 (0x00 — 0xFF). ��, �� �� . �� ��, �� TCP/IP �� �� , ��, ��-�� ��, �� ��: Minimize-Delay (16 �� 0x10), Maximize-Throughput (8 �� 0x08), Maximize-Reliability (4 �� 0x04), Minimize-Cost (2 �� 0x02) �� Normal-Service (0 �� 0x00). ��-�� �� Normal-Service, �� 0. �� , �� �� iptables -j TOS -h.

6.5.14. �� TTL

�� TTL ��
�� Time To Live � IP ��. ��
�� — ��
�� Time To Live ��
� �� . �� ?! �� ,
�� , ��
�� , ��
�� TTL, ��
�� , ��
��
��. �� TTL = 64,
�� Linux.

��
��-�� ip-sysctl.txt, ��
��
��.

�� TTL ��
�� mangle � �� . ��
�� 3 ��, �� .

�� 6-24. �� TTL

��	—ttl-set
��	iptables -t mangle -A PREROUTING -i eth0 -j TTL —ttl-set 64
��	�� TTL � �� ��. �� 64. �� , �� �� , �� �� . �� ��, �� «��» �� �� , ��, �� TTL, �� «��» �� �� .
��	—ttl-dec
��	iptables -t mangle -A PREROUTING -i eth0 -j TTL —ttl-dec 1
��	�� TTL �� �� . ��, �� �� TTL �� 53 � �� —ttl-dec 3, �� �� TTL �� 49. �� ��, �� �� TTL �� 1, ��, �� 53 — 3 — 1 = 49.
��	—ttl-inc
��	iptables -t mangle -A PREROUTING -i eth0 -j TTL —ttl-inc 1
��	�� TTL �� �� . �� , �� �� TTL = 53, ��, �� �� —ttl-inc 4, �� �� , �� TTL = 56, �� �� TTL �� , �.�. �� �� 53 + 4 — 1 = 56. �� TTL �� , �� �� «��» �� �� (traceroutes). �� �� �� , � �� , �� �� �� . �� �� Ttl-inc.txt.

6.5.15. �� ULOG

�� ULOG ��
�� . ��
�� LOG, ��
��. �� , ��, ��
�� netlink, ��
��
�� (�� , �� MySQL � ��.)
� � ��
(��) ��
�� . �� ULOGD
�� ULOGD project page.

�� 6-25. �� ULOG

��	—ulog-nlgroup
��	iptables -A INPUT -p TCP —dport 22 -j ULOG —ulog-nlgroup 2
��	�� —ulog-nlgroup �� ULOG � �� netlink �� . �� 32 �� (�� 1 �� 32). �� �� 5-� ��, �� —ulog-nlgroup 5. ��-�� 1-� ��.
��	—ulog-prefix
��	iptables -A INPUT -p TCP —dport 22 -j ULOG —ulog-prefix «SSH connection attempt: «
��	�� —ulog-prefix �� �� , �� LOG. �� �� 32 ��.
��	—ulog-cprange
��	iptables -A INPUT -p TCP —dport 22 -j ULOG —ulog-cprange 100
��	�� —ulog-cprange ��, �� , � ��, �� �� ULOG. �� 100, �� , �� �� 100 �� , �� , �� �� . �� 0, �� , �� ��. �� -�� 0.
��	—ulog-qthreshold
��	iptables -A INPUT -p TCP —dport 22 -j ULOG —ulog-qthreshold 10
��	�� —ulog-qthreshold �� . ��, �� 10, �� , �� �� �� �� 10 ��. ��-�� 1 ��-�� �� ulogd, �� ��.

�� 7. �� rc.firewall

� ��
�� rc.firewall.txt. ��
�� . ��
�� . ��
��
�� , ��
��, � ��
��.

��, ��
�� , ��
�� , ��, ��
��
BASH.

7.1. �� rc.firewall

��, �� rc.firewall.txt (��
�� �� ). ��
�� , �� -��
��. �� ,
��
�� .

7.2. ��
rc.firewall

7.2.1. ��

�� rc.firewall.txt
�� . ��
�� , ��
�� . �� IP �� — ��
�� . �� $INET_IP ��
�� IP ��, ��
DHCP, �� rc.DHCP.firewall.txt,
�� $INET_IFACE ��
��, ��
��. �� , � ��, eth0, eth1, ppp0, tr0
� ��.

�� ,
�� DHCP, PPPoE, ��
��. �� «��»
��. �� , ��
�� . ��
�� , ��
�� , �� .

�� Local Area Network ��
��, ��
��. �� IP �� ,
��, �� , ��
�� .

�� Localhost Configuration, ��
�� . � ��
�� lo � �� IP �� 127.0.0.1. ��
�� Localhost Configuration, �� Iptables
Configuration. �� $IPTABLES, ��
�� iptables (�� /usr/local/sbin/iptables). ��
�� iptables �� , ��
iptables ��
�� (�� /usr/sbin/iptables), ��
�� iptables ��
��.

7.2.2. ��
��

� �� , �� /sbin/depmod -a, ��
��
�� , �� .
��
��. ��, ��
�� LOG, REJECT � MASQUERADE � ��
�� , ��
�� , ��
�� :

/sbin/insmod ipt_LOG
/sbin/insmod ipt_REJECT
/sbin/insmod ipt_MASQUERADE

� ��
�� , �� . ��
�� , ��
�� , ��
�� , ��
� �� . ��
��
��.

� �� , ��
�� , �� .
�� ipt_owner, ��
��
�� , ��,
�� . �� ipt_owner, ��
�� Owner ��
��.

��
«��» �� (state matching). �� ,
�� ,
�� ip_conntrack_* � ip_nat_*. � ��
��
��. ��: �� FTP ��
�� , ��
�� . ��, ��
�� , ��
��, �� FTP �� , ��
�� IP �� . �
��, IP ��, ��
��, �� , ��
�� , � ��
�� . �� FTP NAT
��
��, �� FTP ��
�� IP ��
�� . ��
�� DCC �� . ��
�� IP ��
�� IRC, ��
�� . ��
�� FTP � IRC
�� . ��, ��
�� DCC, �� . ��
�� , �� DCC «��»
��. ��
�� . ��
�� DCC �� , ��
��
�� , ��
�� «��». ��
��
��. �� IP
�� .

��
mIRC DCC �� , ��
IRC-�� — ��
�� �� mIRC DCC �
��
��.

�� conntrack � nat
��
��. �� ,
�� iptables. ��
��, �� patch-o-matic �
�� . �� — ��
�� ��.

��, �� ip_nat_irc �
ip_nat_ftp �� ,
�� , ��
�� (Network Adress Translation) ��
�� FTP � IRC. ��
�� ip_conntrack_irc �
ip_conntrack_ftp �� NAT.

7.2.3. �� /proc

�� (IP forwarding),
�� /proc/sys/net/ipv4/ip_forward ��
��:

echo «1» >
/proc/sys/net/ipv4/ip_forward

��
�� (IP forwarding). � ��
�� , ��
��
iptables. �� (IP
forwarding) �� , ��
�� , �� , ��
�� , ��
�� , ��
�� . ��, ��
�� , ��
�� .
��, � ��
(IP forwarding) ��
��. ��
�� .

�� IP, (��
�� SLIP, PPP �� DHCP) ��
��:

echo «1» >
/proc/sys/net/ipv4/ip_dynaddr

�� , ��
��
��. ��
/proc �� . ��
��
��.

�� rc.firewall.txt � ��
�� , ��
��
(non-required) �� /proc. ��
�� — ��
�� , �� , ��
�� , ��
��.

7.2.4. ��
��

�� , �
�� — � �� , ��
�� rc.firewall.txt. ��
��
�� . �
��, �� «��
��». ��
� �� ,
�� , �� .

�� , �
�� , ��
�� . ��
��, �� TCP ��
(� �� ICMP, � �� UDP), � �� TCP ��
�� , �� TCP ��, ��
�� . ��
��
netfilter. � ��, ��
�� , ��
��
� ��.

�� — �� . �
��, �� , ��
�� , �� (firewall) �
�� , � �� IP
�� (� �� PPP, SLIP, DHCP � ��). ��
��, ��
��, ��
� �� , ��
�� , ��
��
�� . ��
�� «��
— �� ». ��
��, �� -�� —
DROP. ��
��, �� .

� ��
��.

�� — ��
��. ��
�� (NAT). �� PREROUTING (� ��, ��
�� , ��
�� POSTROUTING, �� , �� SNAT
�� POSTROUTING �� nat ��. ��.), ��
�� . ��,
��, �� FORWARD. ��
�� , �� , ��
�� , ��
��
�� . � ��
��
��, �� , ��
�� (ESTABLISHED � RELATED).

�� -�� — ��
�� , �� .
�� HTTP, FTP, SSH � IDENTD �� . ��
�� INPUT, ��
�� «��» �� OUTPUT. ��
�� , ��
�� , �
�� IP
�� (127.0.0.1). �� , ��
�� , ��
��, ��
�� . ��
�� , ��
�� . � � ��
��
��.

�� FTP ��, �� ,
�� , ��
�� INPUT, ��
�� . � �� , �� ,
�� , ��
�� , �� . � ��
�� .

� ��
�� . ��
�� , ��, tcp_packets, ��
�� TCP �� . ��
�� , ��
�� , �� . � ��
�� allowed. � ��
�� TCP ��
�� . ICMP ��
icmp_packets. ��
�� ICMP ��
��. � �� UDP ��. ��
�� udp_packets, ��
�� UDP ��. ��
�� , ��
�� .

�� ,
��
��, ��
� � �� .

� � �� OUTPUT. ��
�� , ��
��, �� , ��
�� «��» ��, ��
�� , ��
�� , � ��
�� (127.0.0.1) � � �� . � ��
�� OUTPUT, �� (��
��) �� -�� DROP.

7.2.5. ��
��-��

��, �� ,
�� -��.
�� -�� , ��
��

iptables [-P {chain}
{policy}]

�� -�� ,
�� , ��
�� . (�� , �� iptables -P ��
�� , �.�. INPUT, FORWARD, OUTPUT � �.�., �
�� . ��. ��.).

��
��-�� , ��
�� , ��
�� .

7.2.6. ��
�� filter

��, � ��
�� , � ��
�� ! ��
�� .
��
��.

��
�� -N. ��
�� . � ��
�� icmp_packets, tcp_packets, udp_packets � �� allowed, ��
�� tcp_packets. ��
�� $INET_IFACE (�.�. �� ),
�� ICMP �� icmp_packets, �� TCP
�� tcp_packets � �� UDP � �� eth0 ��
udp_packets. ��
�� �� INPUT. ��
�� :

iptables [-N chain]

7.2.6.1. ��
bad_tcp_packets

��
� «��» ��
�� . �� ,
�� NEW, �� SYN ��, � ��
�� SYN/ACK-��, ��
NEW. ��
��
��. ��, �� , ��
�� INVALID.

��
��, �� NEW � ��
�� SYN � ��
��. ��, ��
�� NEW � �� SYN, �� 99% ��
�� . ��
� �� , � ��
«��» ��.

��, �� SYN/ACK-��
NEW �� REJECT, �� . ��
�� SYN/ACK — ��
�� NEW ��
��. ��
�� RST � �� (RST � ��
�� SYN/ACK). ��
�� «��
TCP-��» (Sequence Number Prediction)
�� .

7.2.6.2. �� allowed

TCP ��, �� $INET_IFACE, ��
tcp_packets, ��
�� , ��
�� allowed.

�� , �� SYN ��, �.�. ��
��. ��
��. ��
�� ESTABLISHED �� RELATED. ��
�� SYN ��, � ��
�� , �� ESTABLISHED. ��
�� TCP ��. ��
��
��, �� SYN, ��
��. �� SYN ��
�� , ��
�� . �� , ��
�� TCP/IP, ��
�� , ��
SYN ��, �� 99% ��
�� , �� , ��
��.

7.2.6.3. �� TCP

��, �� TCP ��. ��
��, �� Internet.
�� , ��
��, �� allowed ��
��.

� �� TCP �� 21, ��
�� FTP ��. � ��, � ��
�� RELATED ��, ��,
�� , PASSIVE FTP, �� , ��
�� ip_conntrack_ftp. ��
�� FTP ��, ��
�� ip_conntrack_ftp � ��
�� $IPTABLES -A tcp_packets -p TCP -s 0/0
—dport 21 -j allowed �� rc.firewall.txt.

�� 22 — �� SSH, ��
telnet �� 23 ��. ��
�� (shell) ��
��, �� SSH. �� ,
�� , �� -��
��
��. �� ,
�� .

�� 80 — �� HTTP, �� — web ��,
�� , �� web ��.

� �� 113, �� IDENTD �
�� IRC, � ��.
��, �� oidentd ��
�� (��) �
�� . oidentd ��
IDENTD ��
��.

��
�� , ��
� �� tcp_packets � ��
�� .

7.2.6.4. �� UDP

�� UDP �� INPUT �� udp_packets �� TCP ��, ��
�� .
�� — ��
��, ��
��. �� , ��
��
��. ��, ��
�� (��
��) �� , ��
�� ESTABLISHED �� RELATED.

�� , �� 53, ��
«��» DNS, �� UDP �� , ��
��, �� 53-� �� ,
�� . �� DNS ��
��, ��
��.

� �� 123, �� NTP
(network time protocol). ��
�� .
��, �� , ��
��, ��
�� .

�� 2074 ��
��, �� speak freely, ��
�� .

� �� — ICQ, �� 4000. ��
��, �� ICQ-��
�� .

�� ,
�� -�� . ��
��, �� .
�� — �� , ��
�� 135 �� 139. ��
�� SMB � NetBIOS �� Microsoft. ��
��
�� Microsoft Network. ��
�� DHCP �� . ��
��
�� , �� IP ��
�� .

��
�� (� ��
��). �� , ��
�� , ��
�� INPUT, ��, ��
�� «��»
�� — ��
�� .

7.2.6.5. �� ICMP

�� ICMP ��. ��
� eth0 � �� INPUT, ��
�� icmp_packets. � ��
�� ICMP ��. ��
�� ICMP Echo Request, TTL equals 0 during transit � TTL equals 0 during reassembly.
�� ICMP ��
�� , ��
�� RELATED.

�� ICMP ��
�� , �� RELATED (��
�� ). ��
��
��

��
��: ICMP Echo Request ��
��, �� , ��
��. �� , ��
�� «��» � �� ICMP Echo Request, ��
�� ping � �� , ��
��, ��.

Time Exceeded (�.�., TTL equals 0 during transit � TTL equals 0 during reassembly).
�� , ��
�� TTL, � �� ,
�� 1. �� TTL �� , ��
�� Time Exceeded. ��, ��
�� (traceroute) �� , ��
�� TTL �� 1, ��
��
�� Time Exceeded, ��,
�� TTL = 2 � ��
Time Exceeded, � �� , ��
�� .

�� ICMP ��
�� �� ICMP ��
�� ICMP ��
�� :

The Internet Control Message
Protocol
RFC 792 — Internet Control
Message Protocol — �� J. Postel.

�� ICMP ��, ��
�� , �� -�� , ��
�� , �� .

7.2.7. �� INPUT

�� INPUT, �� , ��
�� , ��
�� . ��
��
�� , ��
«��» �� . ��
��
�� . ��
�� , �� .

��
«��» ��. ��
��
bad_tcp_packets. � ��
�� , �� 99% ��
�� «��». ��
�� (��) �
«��».

�� , ��
�� , �� , ��
� �� , ��
�� (lo) � ��
�� (�� IP ��). ��
�� , ��
��
�� Internet. ��, ��
��, �� , ��
�� , ��
��.

�� , ��
$INET_IFACE, �� , ��
�� ESTABLISHED �� RELATED (��
�� ). ��
�� , �� allowed. �
� �� , ��
�� allowed ��
tcp_packets, ��
��, ��
��
�� allowed.

�� , ��
Internet. �� , �� INPUT � �� $INET_IFACE ��
�� , � �� . TCP
�� tcp_packets, UDP ��
� �� udp_packets � ICMP ��
� �� icmp_packets. �� , ��
�� «��» TCP ��, �� UDP �
�� ICMP, ��
��
��. �� , ��
�� . �� — ��
��. � ��
�� Pentium III � ��, � �� 100
�� ,
�� «�� »
�� .

�� (��-��
��). �� , �� Microsoft
Network �� «�� » ��
�� Multicast (��) ��
�� 224.0.0.0/8. ��
�� «��» ��
��, ��
Microsoft Network. ��
�� (��-�� ) � ��
udp_packets, �� �� UDP.

�� , ��
�� INPUT ��
��-��, �� , ��
�� . ��
�� , ��
�� — �� 3-� � ��, ��
��
��
�� (��), ��
��.

�� INPUT ��
�� DROP, ��
�� -��.
�� -��
��-��.

7.2.8. �� FORWARD

�� FORWARD ��
�� . �� TCP ��
�� bad_tcp_packets, ��
�� INPUT. �� bad_tcp_packets ��
�� , �� ,
�� , �� . �� TCP
��, �� , ��
�� .

��, ��
��. ��, ��
� �� , ��
��, �� ESTABLISHED �� RELATED, �.�. ��
��
��.

� � ��
�� , �� «IPT FORWARD packet died:
«, �� , � �� , ��
�� , �� INPUT.

7.2.9. �� OUTPUT

�� , � ��
��
��. �� , ��
�� $LOCALHOST_IP, $LAN_IP �� $STATIC_IP. ��
�� , ��
��, �� , ��
��, �� . � � �� , �
�� «��» ��, ��
�� .
�� , �� ,
�� -�� — DROP.

7.2.10. �� PREROUTING ��
nat

� ��
� ��, �� , ��
�� , ��
�� (DNAT) ��
�� INPUT �� FORWARD.

�� , ��
�� , �
�� , ��
�� .

7.2.11. �� SNAT � ��
POSTROUTING

� �� — �� SNAT. �� .
�� nat, � ��
POSTROUTING, ��
�� , ��
��, �� Internet. � ��
�� , � ��
�� . �� ,
�� .
�� -t �� , � ��
�� nat. �� -A �� (Add) ��
� �� POSTROUTING, �� -o $INET_IFACE ��
��, � � �� —
SNAT. �� , �� ,
��
«��», �.�. �� , ��
�� . ��
�� —to-source � �� IP
��

� �� SNAT �� MASQUERADE �� . ��
— ��, ��
�� , �� IP ��. ��
�� , �� SNAT ��
��. ��, �� IP
��, �� MASQUERADE, ��
�� , ��
�� IP ��, ��
��. ��, �� SNAT ��
�� , ��
��. �� MASQUERADE, ��
rc.DHCP.firewall.txt.

�� 8. ��

�� , ��
�� , � �� . ��
��, � ��
��. �� , �� «��»
�� . ��
�� .

8.1. ��
rc.firewall.txt

�� , �� , ��
�� . �� , ��
�� , ��
�� . ��
�� . �� ,
��
�� .

�� , ��
�� .
��
�� .

8.1.1. ��

�� — ��, ��
��. �� , �� , ��
�� , �� , ��
�� .

Configuration — ��
�� , �� .
�� , � �� , ��
�� .
1. Internet — ��
  ��, �� Internet.
  �� , ��
  �� . �� , ��
  �� , ��
  ��, �� , ��
  �� Internet.
  1. DHCP — ��
    �� DHCP ��, ��
    �� .
  2. PPPoE — ��
    �� PPPoE ��.
2. LAN — ��
  �� , ��
  �� , �� .
  �� , ��
  �� .
3. DMZ — ��
  �� DMZ. � ��
  �� , �.�. ��
  �� , �� , ��
  �� . (DMZ — de-militarized zone.
  ��
  ��, � �� , ��:
  DNS, MAIL, WEB � �.�, � ��
  �� . ��. ��.)
4. Localhost — ��
  �� (localhost). � ��
  �� , ��, ��
  ��, � �� .��
  ��, ��
  ��.
5. iptables — ��
  �� iptables. � ��
  �� ,
  �� iptables.
6. Other — ��
  �� , ��
  �� .

Module loading — ��
�� . ��
�� , � ��
�� .

�� . �� ,
�� , ��
�� .
��, � �� , ��
�� .

Required modules — ��
�� , ��
�� .
Non-required modules — ��
�� , ��
�� . ��
�� . �� , ��
�� .

proc configuration — ��
�� /proc. ��
�� — �� , �� ,
�� -��, �
�� -��. ��
/proc �� , ��
��.
1. Required proc configuration
  — ��
  �� /proc. ��
  �� , ��,
  ��
  �� .
2. Non-required proc
  configuration — ��
  ��-�� /proc, ��
  �� . ��
  ��, ��
  �� . ��
  �� /proc.

rules set up — � ��
��, �� , �� , ��
�� . � ��
�� . ��
�� , ��
��. � ��
�� , � �� iptables -L.

Filter table — ��
�� filter. ��
�� .

Set policies —
�� -��
��. �� DROP ��
�� filter, � �� ,
�� . ��
��, �� .
Create user specified
chains — � �� , ��
�� , ��
�� . ��
��
��, �� .
Create content in user
specified chains — ��
�� , ��
��. �� , ��
��
�� — �� ,
�� . ��
�� .

INPUT chain — � ��
��
INPUT.

�� , � ��
�� , ��
�� iptables -L.
�� , ��
�� , ��, ��
��
�� , ��
��
��
��.

FORWARD chain — ��
�� FORWARD
OUTPUT chain — ��
�� filter, ��
OUTPUT.

nat table — ��
filter �� nat. ��
�� . �� — ��
�� NAT �� , ��
�� (�� , ��
NAT �� , ��
��). ��, � �� nat ��
�� , ��
filter. �� filter �� ,
� �� nat — �� , �
�� mangle. ��
�� nat. ��
��, �� .
1. Set policies — ��
  ��
  �� nat. ��, �
  �� ACCEPT. ��
  �� , � ��
  �� «��» (DROP) ��.
  ��
  �� -��
  ��. � ��
  ��, ��
  �� .
2. Create user specified
  chains — ��
  �� nat.
  �� , ��
  �� . �� , ��
  ��
  �� .
3. Create content in user
  specified chains — ��
  �� nat. ��
  ��
  filter. � �� , ��
  �� .
4. PREROUTING chain —
  �� PREROUTING �� DNAT. �
  �� DNAT �� , ��
  �� , ��
  «�� » � ��
  �� . � ��
  �� , ��
  �� ,
  �� DNAT ��.
5. POSTROUTING chain —
  �� POSTROUTING �� ,
  �� , ��
  �� ,
  ��
  �� . ��
  �� SNAT, �� , ��
  �� MASQUERADE.
6. OUTPUT chain — ��
  OUTPUT ��
  ��. ��
  �� . ��
  �� , ��
  ��, � � ��
  �� .
mangle table — ��
mangle — �� . ��
� �� , ��
�� , ��
�� TTL �� TOS � ��. ��
��, � ��
��, � �� , ��
��, ��
��.
1. Set policies — ��
  �� -��. ��
  �� , ��
  nat. ��
  ��, � ��
  ��. � ��
  ��
  mangle, � �� .
2. Create user specified
  chains — ��
  ��. �� mangle
  � ��, � ��
  �� . ��, ��
  �� .
3. Create content in user
  specified chains — ��
  ��
  ��, ��
  ��.
4. PREROUTING — � ��
  �� .
5. INPUT chain — � ��
  �� .
6. FORWARD chain — � ��
  �� .
7. OUTPUT chain — � ��
  �� .
8. POSTROUTING chain — �
  ��
  ��.

��, �� , ��
��
��.

�� , ��
��, � �� ,
�� . � ��
��
��, �� — ��
��.

8.2. rc.firewall.txt

�� rc.firewall.txt — �� , ��
�� . �� �� rc.firewall
�� . ��
�� , ��
�� Internet. ��
��, �� IP ��, �
�� DHCP, PPP, SLIP �� ,
�� IP ��. � ��
�� rc.DHCP.firewall.txt

�� , ��
�� , �� . ��
�� ,
��, �� ,
��
�� .

CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_TARGET_LOG

8.3. rc.DMZ.firewall.txt

�� rc.DMZ.firewall.txt �� ,
�� , ��
«�� » � ��
Internet. �� , �
�� , ��, �� NAT «��
��», �� , ��
�� IP ��.

�� , ��
�� , �� . ��
��

CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_TARGET_LOG

�� , ��
�� . �� IP
�� 192.168.0.0/24 � ��
��. �� 192.168.1.0/24 � ��
�� (DMZ), ��
�� (NAT) «��
��». ��, �� -��
�� DNS_IP, �� DNAT �� DNS � DMZ. �� DNAT �� , �� DNS ��
�� , �� DMZ_DNS_IP, � �� DNS_IP. ��
�� :

$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $DNS_IP \
--dport 53 -j DNAT --to-destination $DMZ_DNS_IP

�� , �� DNAT ��
�� PREROUTING �� nat. ��
��, �� TCP �� $INET_IFACE � �� IP, ��
�� $DNS_IP, � �� 53. ��
�� , ��
��, �� DNAT. �� DNAT ��
�� —to-destination $DMZ_DNS_IP. ��
�� , ��
�� $DMZ_DNS_IP �� $DNS_IP, ��
��
�� .

�� DNAT, ��
� �� . �� -��
��
��, �� — ��
�� .

8.4. rc.DHCP.firewall.txt

�� The rc.DHCP.firewall.txt ��
�� rc.firewall.txt. ��,
�� STATIC_IP, ��
�� rc.firewall.txt. �� , ��
rc.firewall.txt �� IP
��. ��, �� — ��.
�� DHCP, PPP � SLIP �� .

�� , ��
�� , �� . ��
��

CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_TARGET_MASQUERADE
CONFIG_IP_NF_TARGET_LOG

��
�� STATIC_IP � ��
��. �� INET_IFACE. �� -d $STATIC_IP �� -i $INET_IFACE. �� ,
�� . (�� , ��
� �� STATIC_IP �� INET_IP ��. ��.)

�� INPUT �� : —in-interface $LAN_IFACE —dst
$INET_IP. ��
�� . ��,
�� HTTP ��. ��
�� , ��
�� , �� , ��
�� «��» �� . ��, ��
�� NAT, �� DNS IP �� HTTP ��,
�� IP. ��
�� IP ��,
�� , �� INPUT �� . ��
��
�� IP ��, �� , ��
��, �� , �� LAN
�� INET_IP � �� ACCEPT �� .

�� , ��
�� , ��
�� IP. ��, �� ,
�� IP �� ifconfig � ��
�� (�� ),
�� «��» �� .
�� linuxguruz.org ��
��, �� . �� linuxguruz.org
��
��.

�� rc.firewall.txt. �
�� rc.firewall.txt, ��
��, �� rc.DHCP.firewall.txt ��
�� .

��, ��
��:

INET_IP=`ifconfig $INET_IFACE | grep inet | cut -d : -f 2 | \
cut -d ' ' -f 1`

�� IP ��
��. �� IP ��
�� retreiveip.txt. ��
�� , �� .

�� , ��
�� PPP, ��
�� «��» ��, ��
��, ��-�� , ��
�� NEW � �� SYN. (�� NEW � ��
�� SYN). ��
�� , ��
�� .
��, �� ,
��
��, � �� .
�� , ��
��, �� . �� , ��
�� .

8.5. rc.UTIN.firewall.txt

�� rc.UTIN.firewall.txt, � ��
��, �� LAN, �� .
��
�� Internet. �� , ��
��, �� , �� , � ��
��. ��
�� POP3, HTTP � FTP.

�� — «��
��, �� ». ��
— �� , ��
��, �� .
�� , ��, �� , ��
�� . ��
�� rc.firewall.txt, ��
�� , �� .

�� , ��
�� , �� . ��
��

CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_TARGET_LOG

This script follows the golden rule to not trust anyone,
not even our own employees. This is a sad fact, but a large
part of the hacks and cracks that a company gets hit by is a
matter of people from their own staff perpetrating the hit.
This script will hopefully give you some clues as to what you
can do with your firewall to strengthen it up. It’s not
very different from the original rc.firewall.txt script, but it does
give a few hints at what we would normally let through
etc.

8.6. rc.test-iptables.txt

�� rc.test-iptables.txt ��
��
�� , � �� ,
��, �� ip_forwarding ��
masquerading � �.�. ��
�� , �� , ��
�� . � ��, � ��
�� LOG �� ping-�� ping-��.
��
��
��. ��
��:

ping -c 1 host.on.the.internet

� �� tail -n 0 -f /var/log/messages.
��
�� .

��
�� . �� , ��
�� ,
�� . �
��
��, �� ,
«��» �� , ��
«�� », � ��
��
�� , ��
�� .

8.7.
rc.flush-iptables.txt

�� rc.flush-iptables.txt � ��
��
�� . � �� , ��
�� -�� ACCEPT �� INPUT, OUTPUT � FORWARD � �� filter. ��
�� -��
�� PREROUTING, POSTROUTING � OUTPUT �� nat. ��
�� , ��
�� . ��, ��
��
�� , ��
��
��-��.

�� -��, ��
�� filter � nat, � ��
��, �� , ��. ��
�� . �� mangle, ��
��
��.

� �� . ��
��, � ��
rc.firewal, �� rc.firewall start
�� . � �� ,
�� , ��
� ��
�� .
��
�� , � ��
�� , ��
�� , �� , � ��
�� .

8.8. Limit-match.txt

�� limit-match.txt ��
�� limit. ��
�� ping-��
�� .

8.9. Pid-owner.txt

�� pid-owner.txt ��
�� —pid-owner. ��, ��
��, ��, �� , ��
�� iptables -L -v.

8.10. Sid-owner.txt

�� sid-owner.txt ��
�� —sid-owner. ��, ��
��, ��, �� , ��
�� iptables -L -v.

8.11. Ttl-inc.txt

�� ttl-inc.txt, ��
�� /�� «��» ��
��, �� .

�� A. ��
��

A.1. ��

��
iptables � �� L, ��
�� �� .
�� :

iptables -L

��
��. ��
�� /etc/services, IP ��
��
DNS. � �� (resolving) ��
�� , ��, ��
192.168.0.0/16 �� DNS ��
�� 192.168.1.1, � ��
��. ��
�� :

iptables -L -n

��
��, ��

iptables -L -n -v

�� -t, ��
�� nat � mangle, ��:

iptables -L -t nat

� �� /proc �� , ��
�� . ��,
��
�� conntrack. �� , ��
��
�� . ��

cat /proc/net/ip_conntrack |
less

A.2. ��
��

��
iptables, ��
��
�� . ��
�� . �� ,
�� -A �� -D � �� . iptables ��
�� . �� , ��
�� , ��
�� . �� ,
�� -D, � �� , ��
�� , ��, �� iptables -D INPUT 10 ��
�� INPUT. (�� , ��
�� iptables -L ��_��
—line-numbers, ��
�� ��. ��.)

��
-F. ��: iptables -F INPUT — ��
�� INPUT, ��
�� -��, ��
�� DROP �� , ��
�� INPUT. ��
��-��, ��
��, �� iptables -P INPUT ACCEPT. (� ��: ��
-t (—table), ��
�� �� � �� filter, ��. ��. )

�� (��
��) �� , �
�� iptables. ��, ��
�� mangle ��
�� , ��
��.

�� B. ��
��

B.1. ��
��

��
�� . ��, ��
��

insmod: iptable_filter: no module by that name found

�� . �� , ��
�� (�� ) ��
��. �� , �� . � ��,
�� , ��
filter. ��
��:

iptables -t filter -L

�� , ��
�� filter. ��
��:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

�� filter ��, ��
��

iptables v1.2.5: can't initialize iptables table `filter': Table \
     does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

�� , �� ,
�� , ��
�� depmod -a, ��
��
�� make modules_install � ��
�� . ��
�� depmod -a. ��
�� , � � ��
�� The Linux Documentation Project.
(�� , ��
�� iptables. ��. ��.)

�� , ��
iptables:

iptables: No chain/target/match by that name

�� , �� , ��
��. �� ,
�� , ��
�� (�� ) ��,
�� . �� , ��
�� .

B.2. �� NEW � ��
�� SYN

�� iptables ��
��, � ��
�� (�� ). ��
��, �� NEW, ��
�� SYN, ��
SYN �� «��»
�� . ��, � ��, ��
�� , ��
ESTABLISHED ��,
�� . ��
��, ��
��, ��
�� , ��
�� .
�� TCP
��. ��
�� INPUT, OUTPUT � FORWARD:

$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG \
     --log-prefix "New not syn:"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

��
��. ��
��
�� .

�� , ��
�� TCP/IP ��
Microsoft. �� , �� , ��,
�� Microsoft ��
NEW � ��
��. ��, ��, �� ,
�� . �� , ��, ��
�� , � �� FIN/ACK, �� netfilter ��
�� conntrack. � �� , ��
�� Microsoft �� , ��
�� NEW, ��
�� SYN �, ��
�� . �� — ��
�� . � �� — ��
�� , �� (��.
�� ) � �� .

�� .
�� -�� , ��
�� LAN, � �� PPP, ��
��. �� , ��
�� conntrack � nat ��. ��
�� , �� rc.firewall.txt �� telnet � �� . ��
�� telnet � ��. �� rc.firewall.txt, � ��
��, �� ,
�� «NEW not SYN». �� telnet �� daemon ��
��, ��
�� NEW, ��
�� SYN, �� , ��,
�� . ��,
��
�� .

B.3. SYN/ACK — ��
�� NEW

�� -�� (�� .
spoofing — ��, ��. ��. ��.), ��
«�� TCP-��»
(Sequence Number Prediction). ��
�� IP-��
�� .

�� Sequence Number Prediction ��
�� [A] — �� , [V] — �� ,
[O] — �� , �� IP-�� .

�� [A] �� SYN-�� (��
��. ��.) �� [V] �
�� IP-�� [O].
�� [V] �� [O] �� SYN/ACK.
��, �� , �� [O] ��
�� RST, ��
�� (�� SYN) � �� ,
��, ��, �� [O] �� (��
��, ��
��, �� SYN/ACK).
�� [O] �� RST, ��
�� , �� [A] ��
�� [V], ��
[O].

�� RST-�� , �� , ��
�� [V], ��
�� . ��
�� RST � �� (RST
� �� SYN/ACK). ��
�� , �� NEW �
�� SYN, �� SYN/ACK-��
«��» �� . ��, ��
�� bad_tcp_packets ��:

iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset

� ��
�� [O] � ��
�� . ��
�� . � ��
�� , ��
�� . �� , �� ,
�� , ��
��.

B.4. �� Internet,
�� IP-��

� ��
�� (Internet Service Providers), ��
IP ��, �� IANA �� . ��,
Swedish Internet Service Provider � ��
Telia �� DNS (�� 10.x.x.x). ��, �
�� , ��
��, �� , � �� , ��
IP � �� 10.x.x.x, ��-��
��. �� , ��
�� . �� ,
�� , �� INPUT, �� :

/usr/local/sbin/iptables -t nat -I PREROUTING -i eth1 -s \
     10.0.0.1/32 -j ACCEPT

�� , ��
��
��. �� — ��, ��
�� — ��! ��
�� «��» �� .

B.5. ��
DHCP �� iptables

� ��, �� , ��
�� DHCP. �� ,
�� DHCP �� UDP. ��, ��
�� . ��, �� ,
��, �� DHCP �� $LAN_IFACE, �� DHCP ��
�� . � ��, ��
��, �� . DHCP �� 67 � 68. ��
��, ��
��:

$IPTABLES  -I INPUT -i $LAN_IFACE -p udp --dport 67:68 --sport \
     67:68 -j ACCEPT

�� , ��
�� UDP �� 67 � 68, ��
�� , ��
�� , ��
�� 67 � 68. ��
��, �� DHCP ��
�� «�� ». ��
�� , ��
��.

B.6. �� mIRC DCC

mIRC �� , ��
�� DCC ��
�� . ��
iptables, �� ip_conntrack_irc � ip_nat_irc, ��
�� . ��
��, �� mIRC ��
�� (NAT) �� . � ��, ��
�� iptables, �� , �� .
mIRC �� , ��
«��», �� IRC, �
�� IP � ��
�� , �� DCC ��.

�� «I am behind a firewall»
(«� �� ») � ��
ip_conntrack_irc � ip_nat_irc �� , �� netfilter
�� «Forged DCC send
packet».

� �� — ��
� mIRC � �� iptables �� .

�� C. �� ICMP

�� ICMP ��:

�� C-1. ICMP types

��	��	��	��	��
0	0	Echo Reply	x	�
3	0	Network Unreachable	�	x
3	1	Host Unreachable	�	x
3	2	Protocol Unreachable	�	x
3	3	Port Unreachable	�	x
3	4	Fragmentation needed but no frag. bit set	�	x
3	5	Source routing failed	�	x
3	6	Destination network unknown	�	x
3	7	Destination host unknown	�	x
3	8	Source host isolated (obsolete)	�	x
3	9	Destination network administratively prohibited	�	x
3	10	Destination host administratively prohibited	�	x
3	11	Network unreachable for TOS	�	x
3	12	Host unreachable for TOS	�	x
3	13	Communication administratively prohibited by filtering	�	x
3	14	Host precedence violation	�	x
3	15	Precedence cutoff in effect	�	x
4	0	Source quench	�	�
5	0	Redirect for network	�	�
5	1	Redirect for host	�	�
5	2	Redirect for TOS and network	�	�
5	3	Redirect for TOS and host	�	�
8	0	Echo request	x	�
9	0	Router advertisement	�	�
10	0	Route solicitation	�	�
11	0	TTL equals 0 during transit	�	x
11	1	TTL equals 0 during reassembly	�	x
12	0	IP header bad (catchall error)	�	x
12	1	Required options missing	�	x
13	0	Timestamp request (obsolete)	x	�
14	�	Timestamp reply (obsolete)	x	�
15	0	Information request (obsolete)	x	�
16	0	Information reply (obsolete)	x	�
17	0	Address mask request	x	�
18	0	Address mask reply	x	�

�� D. ��
��

�� , ��
�� :

ip-sysctl.txt — ��
2.4.14. ��, ��
�� .
ip_dynaddr.txt — ��
2.4.14. ��
ip_dynaddr, �� sysctl � ��
/proc.
iptables.8 — �� iptables 1.2.4 �
�� HTML ��
iptables. �� .
The Internet Control Message Protocol —
�� , �� ICMP.
�� (Ralph Walden).
RFC 792 — Internet Control Message
Protocol — ��
ICMP. �� ICMP,
�� . �� J. Postel.
RFC 793 — Transmission Control Protocol
— �� TCP. ��
�� , ��
��, �� TCP ��
��, �� . �� J.
Postel.
http://www.netfilter.org/ — ��
�� netfilter � iptables. ��
�� iptables � netfilter � linux.
Firewall rules table — ��
�� PDF, ��
(Stuart Clark), ��
�� , ��
��.
/etc/protocols — ��
protocols, �� Slackware. ��
�� , �� IP,
ICMP �� TCP.
/etc/services — ��
services, �� Slackware. ��
�� , ��
�� .
Internet Engineering Task Force — ��
�� , ��
�� Internet. ��
�� RFC. �� , ��
� �� , � ��
��.
Linux Advanced Routing and Traffic Control
HOW-TO — �� , ��
��. �� (Bert
Hubert).
Paksecured Linux Kernel patches — ��
�� «��» � ��, ��
Matthew G. Marsh. �� , ��
«��» FTOS.
ULOGD project page — ��
�� ULOGD.
The Linux Documentation Project ��
�� , �� . ��
�� Linux-��.
http://www.netfilter.org/documentation/index.html#FAQ
— �� FAQ (Frequently Asked Questions) �� netfilter
.
http://www.netfilter.org/unreliable-guides/packet-filtering-HOWTO/index.html
— Rusty Russells Unreliable Guide to packet filtering.
��
�� iptables, ��
iptables � netfilter.
http://www.netfilter.org/unreliable-guides/NAT-HOWTO/index.html
— Rusty Russells Unreliable Guide to Network Address
Translation. �� Network Address
Translation � iptables � netfilter, ��
�� (Rusty Russell).
http://www.netfilter.org/unreliable-guides/netfilter-hacking-HOWTO/index.html
— Rusty Russells Unreliable Netfilter Hacking HOWTO. ��
��
netfilter � iptables. �� (Rusty
Russell).
http://www.linuxguruz.org/iptables/ —
�� . ��
�� iptables �� .
http://www.islandsoft.net/veerapen.html
— �� iptables,
��: ��, �� ,
��
«��» �� (banlist)
� iptables.
http://kalamazoolinux.org/presentations/20010417/conntrack.html
— �� .
�� , ��
�� .
http://www.docum.org — ��
��, �� Linux CBQ,
tc � ip. �� — Stef Coene.
http://lists.samba.org/mailman/listinfo/netfilter
— �� (mailing-list) �� netfilter.
�� iptables �
netfilter.

� �� iptables, �� ,
�� .

�� E. ��

� �� , ��
��
��.:

Fabrice Marie, ��
��, �� . � ��
��
DocBook.
Marc Boucher, ��
��
��.
Frode E. Nyboe, ��
�� rc.firewall, ��
��
�� .
Chapman Brad, Alexander W. Janssen, ��
� ��
NAT � filter.
Michiel Brandenburg, Myles Uyema, ��
�� , ��
�� (state matching).
Kent `Artech’ Stahre, ��
�� . � ��, �� , �
Kent — �� ;). � ��
�� .
Anders ‘DeZENT’ Johansson,
�� (ISP), ��
�� , ��
��.
Jeremy `Spliffy’ Smith, ��
�� .

� �� , �� ,
�� . �� , ��
�� .

�� F. ��

Version�1.1.19�(21�May�2003)
http://iptables-tutorial.frozentux.net
By:�Oskar�Andreasson
Contributors:�Peter�van�Kampen,�Xavier�Bartol,�Jon�Anderson,�Thorsten�Bremer

and�Spanish�Translation�Team.

Version�1.1.18�(24�Apr�2003)
http://iptables-tutorial.frozentux.net
By:�Oskar�Andreasson
Contributors:�Stuart�Clark,�Robert�P.�J.�Day,�Mark�Orenstein�and�Edmond�Shwayri.

Version�1.1.17�(6�Apr�2003)
http://iptables-tutorial.frozentux.net
By:�Oskar�Andreasson
Contributors:�Geraldo�Amaral�Filho,�Ondrej�Suchy,�Dino�Conti,�Robert�P.�J.�Day,

Velev�Dimo,�Spencer�Rouser,�Daveonos,�Amanda�Hickman,�Olle�Jonsson�and

Bengt�Aspvall.

Version�1.1.16�(16�Dec�2002)
�http://iptables-tutorial.frozentux.net
�By:�Oskar�Andreasson
�Contributors:�Clemens�Schwaighower,�Uwe�Dippel�and�Dave�Wreski.

Version�1.1.15�(13�Nov�2002)
http://iptables-tutorial.frozentux.net
By:�Oskar�Andreasson
Contributors:�Clemens�Schwaighower,�Uwe�Dippel�and�Dave�Wreski.

Version�1.1.15�(13�Nov�2002)
http://iptables-tutorial.frozentux.net
By:�Oskar�Andreasson
Contributors:�Mark�Sonarte,�A.�Lester�Buck,�Robert�P.�J.�Day,�Togan�Muftuoglu,

Antony�Stone,�Matthew�F.�Barnes�and�Otto�Matejka.�

Version�1.1.14�(14�Oct�2002)
http://iptables-tutorial.frozentux.net
By:�Oskar�Andreasson
Contributors:�Carol�Anne,�Manuel�Minzoni,�Yves�Soun,�Miernik,�Uwe�Dippel,�

Dave�Klipec�and�Eddy�L�O�Jansson.

Version�1.1.13�(22�Aug�2002)
http://iptables-tutorial.haringstad.com
By:�Oskar�Andreasson
Contributors:�Tons�of�people�reporting�bad�HTML�version.

Version�1.1.12�(19�Aug�2002)
http://www.netfilter.org/tutorial/
By:�Oskar�Andreasson
Contributors:�Peter�Schubnell,�Stephen�J.�Lawrence,�Uwe�Dippel,�Bradley�

Dilger,�Vegard�Engen,�Clifford�Kite,�Alessandro�Oliveira,�Tony�Earnshaw,�

Harald�Welte,�Nick�Andrew�and�Stepan�Kasal.

Version�1.1.11�(27�May�2002)
http://www.netfilter.org/tutorial/
By:�Oskar�Andreasson
Contributors:�Steve�Hnizdur,�Lonni�Friedman,�Jelle�Kalf,�Harald�Welte,�

Valentina�Barrios�and�Tony�Earnshaw.

Version�1.1.10�(12�April�2002)
http://www.boingworld.com/workshops/linux/iptables-tutorial/

By:�Oskar�Andreasson
Contributors:�Jelle�Kalf,�Theodore�Alexandrov,�Paul�Corbett,�Rodrigo�

Rubira�Branco,�Alistair�Tonner,�Matthew�G.�Marsh,�Uwe�Dippel,�Evan�

Nemerson�and�Marcel�J.E.�Mol.�

Version�1.1.9�(21�March�2002)
http://www.boingworld.com/workshops/linux/iptables-tutorial/

By:�Oskar�Andreasson
Contributors:�Vince�Herried,�Togan�Muftuoglu,�Galen�Johnson,�Kelly�Ashe,�Janne

Johansson,�Thomas�Smets,�Peter�Horst,�Mitch�Landers,�Neil�Jolly,�Jelle�Kalf,

Jason�Lam�and�Evan�Nemerson.

Version�1.1.8�(5�March�2002)
http://www.boingworld.com/workshops/linux/iptables-tutorial/

By:�Oskar�Andreasson

Version�1.1.7�(4�February�2002)
http://www.boingworld.com/workshops/linux/iptables-tutorial/

By:�Oskar�Andreasson
Contributors:�Parimi�Ravi,�Phil�Schultz,�Steven�McClintoc,�Bill�Dossett,

Dave�Wreski,�Erik�Sjilund,�Adam�Mansbridge,�Vasoo�Veerapen,�Aladdin�and

Rusty�Russell.

Version�1.1.6�(7�December�2001)
http://people.unix-fu.org/andreasson/
By:�Oskar�Andreasson
Contributors:�Jim�Ramsey,�Phil�Schultz,�Giran�B�ge,�Doug�Monroe,�Jasper

Aikema,�Kurt�Lieber,�Chris�Tallon,�Chris�Martin,�Jonas�Pasche,�Jan

Labanowski,�Rodrigo�R.�Branco,�Jacco�van�Koll�and�Dave�Wreski.

Version�1.1.5�(14�November�2001)
http://people.unix-fu.org/andreasson/
By:�Oskar�Andreasson
Contributors:�Fabrice�Marie,�Merijn�Schering�and�Kurt�Lieber.

Version�1.1.4�(6�November�2001)
http://people.unix-fu.org/andreasson
By:�Oskar�Andreasson
Contributors:�Stig�W.�Jensen,�Steve�Hnizdur,�Chris�Pluta�and�Kurt�Lieber.

Version�1.1.3�(9�October�2001)
http://people.unix-fu.org/andreasson
By:�Oskar�Andreasson
Contributors:�Joni�Chu,�N.Emile�Akabi-Davis�and�Jelle�Kalf.

Version�1.1.2�(29�September�2001)
http://people.unix-fu.org/andreasson
By:�Oskar�Andreasson

Version�1.1.1�(26�September�2001)
http://people.unix-fu.org/andreasson
By:�Oskar�Andreasson
Contributors:�Dave�Richardson.

Version�1.1.0�(15�September�2001)
http://people.unix-fu.org/andreasson
By:�Oskar�Andreasson

Version�1.0.9�(9�September�2001)
http://people.unix-fu.org/andreasson
By:�Oskar�Andreasson

Version�1.0.8�(7�September�2001)
http://people.unix-fu.org/andreasson
By:�Oskar�Andreasson

Version�1.0.7�(23�August�2001)
http://people.unix-fu.org/andreasson
By:�Oskar�Andreasson
Contributors:�Fabrice�Marie.

Version�1.0.6
http://people.unix-fu.org/andreasson
By:�Oskar�Andreasson

Version�1.0.5
http://people.unix-fu.org/andreasson
By:�Oskar�Andreasson
Contributors:�Fabrice�Marie.
��

�� G. GNU Free Documentation
License

Version 1.1, March 2000

Copyright (C) 2000 Free Software Foundation, Inc. 59
Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone
is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook,
or other written document «free» in the sense of
freedom: to assure everyone the effective freedom to copy and
redistribute it, with or without modifying it, either
commercially or noncommercially. Secondarily, this License
preserves for the author and publisher a way to get credit
for their work, while not being considered responsible for
modifications made by others.

This License is a kind of «copyleft», which
means that derivative works of the document must themselves
be free in the same sense. It complements the GNU General
Public License, which is a copyleft license designed for free
software.

We have designed this License in order to use it for
manuals for free software, because free software needs free
documentation: a free program should come with manuals
providing the same freedoms that the software does. But this
License is not limited to software manuals; it can be used
for any textual work, regardless of subject matter or whether
it is published as a printed book. We recommend this License
principally for works whose purpose is instruction or
reference.

1. APPLICABILITY AND
DEFINITIONS

This License applies to any manual or other work that
contains a notice placed by the copyright holder saying it
can be distributed under the terms of this License. The
«Document», below, refers to any such manual or
work. Any member of the public is a licensee, and is
addressed as «you».

A «Modified Version» of the Document means any
work containing the Document or a portion of it, either
copied verbatim, or with modifications and/or translated into
another language.

A «Secondary Section» is a named appendix or a
front-matter section of the Document that deals exclusively
with the relationship of the publishers or authors of the
Document to the Document’s overall subject (or to related
matters) and contains nothing that could fall directly within
that overall subject. (For example, if the Document is in
part a textbook of mathematics, a Secondary Section may not
explain any mathematics.) The relationship could be a matter
of historical connection with the subject or with related
matters, or of legal, commercial, philosophical, ethical or
political position regarding them.

The «Invariant Sections» are certain Secondary
Sections whose titles are designated, as being those of
Invariant Sections, in the notice that says that the Document
is released under this License.

The «Cover Texts» are certain short passages of
text that are listed, as Front-Cover Texts or Back-Cover
Texts, in the notice that says that the Document is released
under this License.

A «Transparent» copy of the Document means a
machine-readable copy, represented in a format whose
specification is available to the general public, whose
contents can be viewed and edited directly and
straightforwardly with generic text editors or (for images
composed of pixels) generic paint programs or (for drawings)
some widely available drawing editor, and that is suitable
for input to text formatters or for automatic translation to
a variety of formats suitable for input to text formatters. A
copy made in an otherwise Transparent file format whose
markup has been designed to thwart or discourage subsequent
modification by readers is not Transparent. A copy that is
not «Transparent» is called «Opaque».

Examples of suitable formats for Transparent copies
include plain ASCII without markup, Texinfo input format,
LaTeX input format, SGML or XML using a publicly available
DTD, and standard-conforming simple HTML designed for human
modification. Opaque formats include PostScript, PDF,
proprietary formats that can be read and edited only by
proprietary word processors, SGML or XML for which the DTD
and/or processing tools are not generally available, and the
machine-generated HTML produced by some word processors for
output purposes only.

The «Title Page» means, for a printed book, the
title page itself, plus such following pages as are needed to
hold, legibly, the material this License requires to appear
in the title page. For works in formats which do not have any
title page as such, «Title Page» means the text
near the most prominent appearance of the work’s title,
preceding the beginning of the body of the text.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium,
either commercially or noncommercially, provided that this
License, the copyright notices, and the license notice saying
this License applies to the Document are reproduced in all
copies, and that you add no other conditions whatsoever to
those of this License. You may not use technical measures to
obstruct or control the reading or further copying of the
copies you make or distribute. However, you may accept
compensation in exchange for copies. If you distribute a
large enough number of copies you must also follow the
conditions in section 3.

You may also lend copies, under the same conditions stated
above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies of the Document numbering
more than 100, and the Document’s license notice requires
Cover Texts, you must enclose the copies in covers that
carry, clearly and legibly, all these Cover Texts:
Front-Cover Texts on the front cover, and Back-Cover Texts on
the back cover. Both covers must also clearly and legibly
identify you as the publisher of these copies. The front
cover must present the full title with all words of the title
equally prominent and visible. You may add other material on
the covers in addition. Copying with changes limited to the
covers, as long as they preserve the title of the Document
and satisfy these conditions, can be treated as verbatim
copying in other respects.

If the required texts for either cover are too voluminous
to fit legibly, you should put the first ones listed (as many
as fit reasonably) on the actual cover, and continue the rest
onto adjacent pages.

If you publish or distribute Opaque copies of the Document
numbering more than 100, you must either include a
machine-readable Transparent copy along with each Opaque
copy, or state in or with each Opaque copy a
publicly-accessible computer-network location containing a
complete Transparent copy of the Document, free of added
material, which the general network-using public has access
to download anonymously at no charge using public-standard
network protocols. If you use the latter option, you must
take reasonably prudent steps, when you begin distribution of
Opaque copies in quantity, to ensure that this Transparent
copy will remain thus accessible at the stated location until
at least one year after the last time you distribute an
Opaque copy (directly or through your agents or retailers) of
that edition to the public.

It is requested, but not required, that you contact the
authors of the Document well before redistributing any large
number of copies, to give them a chance to provide you with
an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the
Document under the conditions of sections 2 and 3 above,
provided that you release the Modified Version under
precisely this License, with the Modified Version filling the
role of the Document, thus licensing distribution and
modification of the Modified Version to whoever possesses a
copy of it. In addition, you must do these things in the
Modified Version:

Use in the Title Page (and on the covers, if any) a
title distinct from that of the Document, and from those
of previous versions (which should, if there were any, be
listed in the History section of the Document). You may
use the same title as a previous version if the original
publisher of that version gives permission.
List on the Title Page, as authors, one or more
persons or entities responsible for authorship of the
modifications in the Modified Version, together with at
least five of the principal authors of the Document (all
of its principal authors, if it has less than five).
State on the Title page the name of the publisher of
the Modified Version, as the publisher.
Preserve all the copyright notices of the
Document.
Add an appropriate copyright notice for your
modifications adjacent to the other copyright
notices.
Include, immediately after the copyright notices, a
license notice giving the public permission to use the
Modified Version under the terms of this License, in the
form shown in the Addendum below.
Preserve in that license notice the full lists of
Invariant Sections and required Cover Texts given in the
Document’s license notice.
Include an unaltered copy of this License.
Preserve the section entitled «History», and
its title, and add to it an item stating at least the
title, year, new authors, and publisher of the Modified
Version as given on the Title Page. If there is no
section entitled «History» in the Document,
create one stating the title, year, authors, and
publisher of the Document as given on its Title Page,
then add an item describing the Modified Version as
stated in the previous sentence.
Preserve the network location, if any, given in the
Document for public access to a Transparent copy of the
Document, and likewise the network locations given in the
Document for previous versions it was based on. These may
be placed in the «History» section. You may
omit a network location for a work that was published at
least four years before the Document itself, or if the
original publisher of the version it refers to gives
permission.
In any section entitled «Acknowledgements»
or «Dedications», preserve the section’s
title, and preserve in the section all the substance and
tone of each of the contributor acknowledgements and/or
dedications given therein.
Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section
numbers or the equivalent are not considered part of the
section titles.
Delete any section entitled «Endorsements».
Such a section may not be included in the Modified
Version.
Do not retitle any existing section as
«Endorsements» or to conflict in title with any
Invariant Section.

If the Modified Version includes new front-matter sections
or appendices that qualify as Secondary Sections and contain
no material copied from the Document, you may at your option
designate some or all of these sections as invariant. To do
this, add their titles to the list of Invariant Sections in
the Modified Version’s license notice. These titles must
be distinct from any other section titles.

You may add a section entitled «Endorsements»,
provided it contains nothing but endorsements of your
Modified Version by various parties—for example, statements
of peer review or that the text has been approved by an
organization as the authoritative definition of a
standard.

You may add a passage of up to five words as a Front-Cover
Text, and a passage of up to 25 words as a Back-Cover Text,
to the end of the list of Cover Texts in the Modified
Version. Only one passage of Front-Cover Text and one of
Back-Cover Text may be added by (or through arrangements made
by) any one entity. If the Document already includes a cover
text for the same cover, previously added by you or by
arrangement made by the same entity you are acting on behalf
of, you may not add another; but you may replace the old one,
on explicit permission from the previous publisher that added
the old one.

The author(s) and publisher(s) of the Document do not by
this License give permission to use their names for publicity
for or to assert or imply endorsement of any Modified
Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released
under this License, under the terms defined in section 4
above for modified versions, provided that you include in the
combination all of the Invariant Sections of all of the
original documents, unmodified, and list them all as
Invariant Sections of your combined work in its license
notice.

The combined work need only contain one copy of this
License, and multiple identical Invariant Sections may be
replaced with a single copy. If there are multiple Invariant
Sections with the same name but different contents, make the
title of each such section unique by adding at the end of it,
in parentheses, the name of the original author or publisher
of that section if known, or else a unique number. Make the
same adjustment to the section titles in the list of
Invariant Sections in the license notice of the combined
work.

In the combination, you must combine any sections entitled
«History» in the various original documents,
forming one section entitled «History»; likewise
combine any sections entitled «Acknowledgements»,
and any sections entitled «Dedications». You must
delete all sections entitled «Endorsements.»

6. COLLECTIONS OF
DOCUMENTS

You may make a collection consisting of the Document and
other documents released under this License, and replace the
individual copies of this License in the various documents
with a single copy that is included in the collection,
provided that you follow the rules of this License for
verbatim copying of each of the documents in all other
respects.

You may extract a single document from such a collection,
and distribute it individually under this License, provided
you insert a copy of this License into the extracted
document, and follow this License in all other respects
regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT
WORKS

A compilation of the Document or its derivatives with
other separate and independent documents or works, in or on a
volume of a storage or distribution medium, does not as a
whole count as a Modified Version of the Document, provided
no compilation copyright is claimed for the compilation. Such
a compilation is called an «aggregate», and this
License does not apply to the other self-contained works thus
compiled with the Document, on account of their being thus
compiled, if they are not themselves derivative works of the
Document.

If the Cover Text requirement of section 3 is applicable
to these copies of the Document, then if the Document is less
than one quarter of the entire aggregate, the Document’s
Cover Texts may be placed on covers that surround only the
Document within the aggregate. Otherwise they must appear on
covers around the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you
may distribute translations of the Document under the terms
of section 4. Replacing Invariant Sections with translations
requires special permission from their copyright holders, but
you may include translations of some or all Invariant
Sections in addition to the original versions of these
Invariant Sections. You may include a translation of this
License provided that you also include the original English
version of this License. In case of a disagreement between
the translation and the original English version of this
License, the original English version will prevail.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the
Document except as expressly provided for under this License.
Any other attempt to copy, modify, sublicense or distribute
the Document is void, and will automatically terminate your
rights under this License. However, parties who have received
copies, or rights, from you under this License will not have
their licenses terminated so long as such parties remain in
full compliance.

10. FUTURE REVISIONS OF THIS
LICENSE

The Free Software Foundation may publish new, revised
versions of the GNU Free Documentation License from time to
time. Such new versions will be similar in spirit to the
present version, but may differ in detail to address new
problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing
version number. If the Document specifies that a particular
numbered version of this License «or any later
version» applies to it, you have the option of following
the terms and conditions either of that specified version or
of any later version that has been published (not as a draft)
by the Free Software Foundation. If the Document does not
specify a version number of this License, you may choose any
version ever published (not as a draft) by the Free Software
Foundation.

How to use this License for your
documents

To use this License in a document you have written,
include a copy of the License in the document and put the
following copyright and license notices just after the title
page:

Copyright (c) YEAR YOUR NAME. Permission is granted to
copy, distribute and/or modify this document under the
terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software
Foundation; with the Invariant Sections being LIST THEIR
TITLES, with the Front-Cover Texts being LIST, and with the
Back-Cover Texts being LIST. A copy of the license is
included in the section entitled «GNU Free
Documentation License».

If you have no Invariant Sections, write «with no
Invariant Sections» instead of saying which ones are
invariant. If you have no Front-Cover Texts, write «no
Front-Cover Texts» instead of «Front-Cover Texts
being LIST»; likewise for Back-Cover Texts.

If your document contains nontrivial examples of program
code, we recommend releasing these examples in parallel under
your choice of free software license, such as the GNU General
Public License, to permit their use in free software.

�� H. GNU General Public License

Version 2, June 1991

Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59
Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone
is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

0. Preamble

The licenses for most software are designed to take away
your freedom to share and change it. By contrast, the GNU
General Public License is intended to guarantee your freedom
to share and change free software—to make sure the software
is free for all its users. This General Public License
applies to most of the Free Software Foundation’s
software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is
covered by the GNU Library General Public License instead.)
You can apply it to your programs, too.

When we speak of free software, we are referring to
freedom, not price. Our General Public Licenses are designed
to make sure that you have the freedom to distribute copies
of free software (and charge for this service if you wish),
that you receive source code or can get it if you want it,
that you can change the software or use pieces of it in new
free programs; and that you know you can do these things.

To protect your rights, we need to make restrictions that
forbid anyone to deny you these rights or to ask you to
surrender the rights. These restrictions translate to certain
responsibilities for you if you distribute copies of the
software, or if you modify it.

For example, if you distribute copies of such a program,
whether gratis or for a fee, you must give the recipients all
the rights that you have. You must make sure that they, too,
receive or can get the source code. And you must show them
these terms so they know their rights.

We protect your rights with two steps: (1) copyright the
software, and (2) offer you this license which gives you
legal permission to copy, distribute and/or modify the
software.

Also, for each author’s protection and ours, we want
to make certain that everyone understands that there is no
warranty for this free software. If the software is modified
by someone else and passed on, we want its recipients to know
that what they have is not the original, so that any problems
introduced by others will not reflect on the original
authors’ reputations.

Finally, any free program is threatened constantly by
software patents. We wish to avoid the danger that
redistributors of a free program will individually obtain
patent licenses, in effect making the program proprietary. To
prevent this, we have made it clear that any patent must be
licensed for everyone’s free use or not licensed at
all.

The precise terms and conditions for copying, distribution
and modification follow.

1. TERMS AND CONDITIONS FOR
COPYING, DISTRIBUTION AND MODIFICATION

This License applies to any program or other work
which contains a notice placed by the copyright holder
saying it may be distributed under the terms of this
General Public License. The «Program», below,
refers to any such program or work, and a «work
based on the Program» means either the Program or
any derivative work under copyright law: that is to say,
a work containing the Program or a portion of it, either
verbatim or with modifications and/or translated into
another language. (Hereinafter, translation is included
without limitation in the term «modification».)
Each licensee is addressed as «you».

Activities other than copying, distribution and
modification are not covered by this License; they are
outside its scope. The act of running the Program is not
restricted, and the output from the Program is covered
only if its contents constitute a work based on the
Program (independent of having been made by running the
Program). Whether that is true depends on what the
Program does.
You may copy and distribute verbatim copies of the
Program’s source code as you receive it, in any
medium, provided that you conspicuously and appropriately
publish on each copy an appropriate copyright notice and
disclaimer of warranty; keep intact all the notices that
refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of
this License along with the Program.

You may charge a fee for the physical act of
transferring a copy, and you may at your option offer
warranty protection in exchange for a fee.
You may modify your copy or copies of the Program or
any portion of it, thus forming a work based on the
Program, and copy and distribute such modifications or
work under the terms of Section 1 above, provided that
you also meet all of these conditions:
1. You must cause the modified files to carry
  prominent notices stating that you changed the files
  and the date of any change.
2. You must cause any work that you distribute or
  publish, that in whole or in part contains or is
  derived from the Program or any part thereof, to be
  licensed as a whole at no charge to all third parties
  under the terms of this License.
3. If the modified program normally reads commands
  interactively when run, you must cause it, when
  started running for such interactive use in the most
  ordinary way, to print or display an announcement
  including an appropriate copyright notice and a
  notice that there is no warranty (or else, saying
  that you provide a warranty) and that users may
  redistribute the program under these conditions, and
  telling the user how to view a copy of this License.
  (Exception: if the Program itself is interactive but
  does not normally print such an announcement, your
  work based on the Program is not required to print an
  announcement.)
These requirements apply to the modified work as a
whole. If identifiable sections of that work are not
derived from the Program, and can be reasonably
considered independent and separate works in themselves,
then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But
when you distribute the same sections as part of a whole
which is a work based on the Program, the distribution of
the whole must be on the terms of this License, whose
permissions for other licensees extend to the entire
whole, and thus to each and every part regardless of who
wrote it.

Thus, it is not the intent of this section to claim
rights or contest your rights to work written entirely by
you; rather, the intent is to exercise the right to
control the distribution of derivative or collective
works based on the Program.

In addition, mere aggregation of another work not
based on the Program with the Program (or with a work
based on the Program) on a volume of a storage or
distribution medium does not bring the other work under
the scope of this License.
You may copy and distribute the Program (or a work
based on it, under Section 2) in object code or
executable form under the terms of Sections 1 and 2 above
provided that you also do one of the following:
1. Accompany it with the complete corresponding
  machine-readable source code, which must be
  distributed under the terms of Sections 1 and 2 above
  on a medium customarily used for software
  interchange; or,
2. Accompany it with a written offer, valid for at
  least three years, to give any third party, for a
  charge no more than your cost of physically
  performing source distribution, a complete
  machine-readable copy of the corresponding source
  code, to be distributed under the terms of Sections 1
  and 2 above on a medium customarily used for software
  interchange; or,
3. Accompany it with the information you received as
  to the offer to distribute corresponding source code.
  (This alternative is allowed only for noncommercial
  distribution and only if you received the program in
  object code or executable form with such an offer, in
  accord with Subsection b above.)
The source code for a work means the preferred form of
the work for making modifications to it. For an
executable work, complete source code means all the
source code for all modules it contains, plus any
associated interface definition files, plus the scripts
used to control compilation and installation of the
executable. However, as a special exception, the source
code distributed need not include anything that is
normally distributed (in either source or binary form)
with the major components (compiler, kernel, and so on)
of the operating system on which the executable runs,
unless that component itself accompanies the
executable.

If distribution of executable or object code is made
by offering access to copy from a designated place, then
offering equivalent access to copy the source code from
the same place counts as distribution of the source code,
even though third parties are not compelled to copy the
source along with the object code.
You may not copy, modify, sublicense, or distribute
the Program except as expressly provided under this
License. Any attempt otherwise to copy, modify,
sublicense or distribute the Program is void, and will
automatically terminate your rights under this License.
However, parties who have received copies, or rights,
from you under this License will not have their licenses
terminated so long as such parties remain in full
compliance.
You are not required to accept this License, since you
have not signed it. However, nothing else grants you
permission to modify or distribute the Program or its
derivative works. These actions are prohibited by law if
you do not accept this License. Therefore, by modifying
or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to
do so, and all its terms and conditions for copying,
distributing or modifying the Program or works based on
it.
Each time you redistribute the Program (or any work
based on the Program), the recipient automatically
receives a license from the original licensor to copy,
distribute or modify the Program subject to these terms
and conditions. You may not impose any further
restrictions on the recipients’ exercise of the
rights granted herein. You are not responsible for
enforcing compliance by third parties to this
License.
If, as a consequence of a court judgment or allegation
of patent infringement or for any other reason (not
limited to patent issues), conditions are imposed on you
(whether by court order, agreement or otherwise) that
contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you
cannot distribute so as to satisfy simultaneously your
obligations under this License and any other pertinent
obligations, then as a consequence you may not distribute
the Program at all. For example, if a patent license
would not permit royalty-free redistribution of the
Program by all those who receive copies directly or
indirectly through you, then the only way you could
satisfy both it and this License would be to refrain
entirely from distribution of the Program.

If any portion of this section is held invalid or
unenforceable under any particular circumstance, the
balance of the section is intended to apply and the
section as a whole is intended to apply in other
circumstances.

It is not the purpose of this section to induce you to
infringe any patents or other property right claims or to
contest validity of any such claims; this section has the
sole purpose of protecting the integrity of the free
software distribution system, which is implemented by
public license practices. Many people have made generous
contributions to the wide range of software distributed
through that system in reliance on consistent application
of that system; it is up to the author/donor to decide if
he or she is willing to distribute software through any
other system and a licensee cannot impose that
choice.

This section is intended to make thoroughly clear what
is believed to be a consequence of the rest of this
License.

If the distribution and/or use of the Program is
restricted in certain countries either by patents or by
copyrighted interfaces, the original copyright holder who
places the Program under this License may add an explicit
geographical distribution limitation excluding those
countries, so that distribution is permitted only in or
among countries not thus excluded. In such case, this
License incorporates the limitation as if written in the
body of this License.
The Free Software Foundation may publish revised
and/or new versions of the General Public License from
time to time. Such new versions will be similar in spirit
to the present version, but may differ in detail to
address new problems or concerns.

Each version is given a distinguishing version number.
If the Program specifies a version number of this License
which applies to it and «any later version»,
you have the option of following the terms and conditions
either of that version or of any later version published
by the Free Software Foundation. If the Program does not
specify a version number of this License, you may choose
any version ever published by the Free Software
Foundation.
If you wish to incorporate parts of the Program into
other free programs whose distribution conditions are
different, write to the author to ask for permission. For
software which is copyrighted by the Free Software
Foundation, write to the Free Software Foundation; we
sometimes make exceptions for this. Our decision will be
guided by the two goals of preserving the free status of
all derivatives of our free software and of promoting the
sharing and reuse of software generally.
NO WARRANTY

BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE
IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED
BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN
WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM «AS IS» WITHOUT WARRANTY OF
ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO
THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.
SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST
OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR
AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY
OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE
PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY
TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES
SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE
PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH
HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY
OF SUCH DAMAGES.

END OF TERMS AND CONDITIONS

2. How to Apply These Terms to Your New
Programs

If you develop a new program, and you want it to be of the
greatest possible use to the public, the best way to achieve
this is to make it free software which everyone can
redistribute and change under these terms.

To do so, attach the following notices to the program. It
is safest to attach them to the start of each source file to
most effectively convey the exclusion of warranty; and each
file should have at least the «copyright» line and
a pointer to where the full notice is found.

<one�line�to�give�the�program’s�name�and�a�brief�idea�of�what�it�does.>

Copyright�(C)�<year>��<name�of�author>
��

This program is free software; you can redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation;
either version 2 of the License, or (at your option) any
later version.

This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License for more
details.

You should have received a copy of the GNU General
Public License along with this program; if not, write to
the Free Software Foundation, Inc., 59 Temple Place, Suite
330, Boston, MA 02111-1307 USA

Also add information on how to contact you by electronic
and paper mail.

If the program is interactive, make it output a short
notice like this when it starts in an interactive mode:

Gnomovision version 69, Copyright (C) year name of
author Gnomovision comes with ABSOLUTELY NO WARRANTY; for
details type `show w’. This is free software, and you
are welcome to redistribute it under certain conditions;
type `show c’ for details.

The hypothetical commands `show w’ and `show c’
should show the appropriate parts of the General Public
License. Of course, the commands you use may be called
something other than `show w’ and `show c’; they
could even be mouse-clicks or menu items—whatever suits your
program.

You should also get your employer (if you work as a
programmer) or your school, if any, to sign a «copyright
disclaimer» for the program, if necessary. Here is a
sample; alter the names:

Yoyodyne,�Inc.,�hereby�disclaims�all�copyright�interest�in�the�program

`Gnomovision’�(which�makes�passes�at�compilers)�written�by�James�Hacker.

��

<signature�of�Ty�Coon>,�1�April�1989
Ty�Coon,�President�of�Vice
��

This General Public License does not permit incorporating
your program into proprietary programs. If your program is a
subroutine library, you may consider it more useful to permit
linking proprietary applications with the library. If this is
what you want to do, use the GNU Library General Public
License instead of this License.

�� I. ��

I.1. �� rc.firewall

#!/bin/sh
#
# rc.firewall - Initial SIMPLE IP Firewall script for Linux 2.4.x and iptables
#
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

###########################################################################
#
# 1. Configuration options.
#

#
# 1.1 Internet Configuration.
#

INET_IP="194.236.50.155"
INET_IFACE="eth0"
INET_BROADCAST="194.236.50.255"

#
# 1.1.1 DHCP
#

#
# 1.1.2 PPPoE
#

#
# 1.2 Local Area Network configuration.
#
# your LAN's IP range and localhost IP. /24 means to only use the first 24
# bits of the 32 bit IP address. the same as netmask 255.255.255.0
#

LAN_IP="192.168.0.2"
LAN_IP_RANGE="192.168.0.0/16"
LAN_IFACE="eth1"

#
# 1.3 DMZ Configuration.
#

#
# 1.4 Localhost Configuration.
#

LO_IFACE="lo"
LO_IP="127.0.0.1"

#
# 1.5 IPTables Configuration.
#

IPTABLES="/usr/sbin/iptables"

#
# 1.6 Other Configuration.
#

###########################################################################
#
# 2. Module loading.
#

#
# Needed to initially load modules
#

/sbin/depmod -a

#
# 2.1 Required modules
#

/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_mangle
/sbin/modprobe iptable_nat
/sbin/modprobe ipt_LOG
/sbin/modprobe ipt_limit
/sbin/modprobe ipt_state

#
# 2.2 Non-Required modules
#

#/sbin/modprobe ipt_owner
#/sbin/modprobe ipt_REJECT
#/sbin/modprobe ipt_MASQUERADE
#/sbin/modprobe ip_conntrack_ftp
#/sbin/modprobe ip_conntrack_irc
#/sbin/modprobe ip_nat_ftp
#/sbin/modprobe ip_nat_irc

###########################################################################
#
# 3. /proc set up.
#

#
# 3.1 Required proc configuration
#

echo "1" > /proc/sys/net/ipv4/ip_forward

#
# 3.2 Non-Required proc configuration
#

#echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
#echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr

###########################################################################
#
# 4. rules set up.
#

######
# 4.1 Filter table
#

#
# 4.1.1 Set policies
#

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

#
# 4.1.2 Create userspecified chains
#

#
# Create chain for bad tcp packets
#

$IPTABLES -N bad_tcp_packets

#
# Create separate chains for ICMP, TCP and UDP to traverse
#

$IPTABLES -N allowed
$IPTABLES -N tcp_packets
$IPTABLES -N udp_packets
$IPTABLES -N icmp_packets

#
# 4.1.3 Create content in userspecified chains
#

#
# bad_tcp_packets chain
#

$IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset 
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \
--log-prefix "New not syn:"
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

#
# allowed chain
#

$IPTABLES -A allowed -p TCP --syn -j ACCEPT
$IPTABLES -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A allowed -p TCP -j DROP

#
# TCP rules
#

$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 21 -j allowed
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 22 -j allowed
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 80 -j allowed
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 113 -j allowed

#
# UDP ports
#

#$IPTABLES -A udp_packets -p UDP -s 0/0 --destination-port 53 -j ACCEPT
#$IPTABLES -A udp_packets -p UDP -s 0/0 --destination-port 123 -j ACCEPT
$IPTABLES -A udp_packets -p UDP -s 0/0 --destination-port 2074 -j ACCEPT
$IPTABLES -A udp_packets -p UDP -s 0/0 --destination-port 4000 -j ACCEPT

#
# In Microsoft Networks you will be swamped by broadcasts. These lines 
# will prevent them from showing up in the logs.
#

#$IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d $INET_BROADCAST \
#--destination-port 135:139 -j DROP

#
# If we get DHCP requests from the Outside of our network, our logs will 
# be swamped as well. This rule will block them from getting logged.
#

#$IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d 255.255.255.255 \
#--destination-port 67:68 -j DROP

#
# ICMP rules
#

$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

#
# 4.1.4 INPUT chain
#

#
# Bad TCP packets we don't want.
#

$IPTABLES -A INPUT -p tcp -j bad_tcp_packets

#
# Rules for special networks not part of the Internet
#

$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s $LAN_IP_RANGE -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LO_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LAN_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $INET_IP -j ACCEPT

#
# Special rule for DHCP requests from LAN, which are not caught properly
# otherwise.
#

$IPTABLES -A INPUT -p UDP -i $LAN_IFACE --dport 67 --sport 68 -j ACCEPT

#
# Rules for incoming packets from the internet.
#

$IPTABLES -A INPUT -p ALL -d $INET_IP -m state --state ESTABLISHED,RELATED \
-j ACCEPT
$IPTABLES -A INPUT -p TCP -i $INET_IFACE -j tcp_packets
$IPTABLES -A INPUT -p UDP -i $INET_IFACE -j udp_packets
$IPTABLES -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets

#
# If you have a Microsoft Network on the outside of your firewall, you may 
# also get flooded by Multicasts. We drop them so we do not get flooded by 
# logs
#

#$IPTABLES -A INPUT -i $INET_IFACE -d 224.0.0.0/8 -j DROP

#
# Log weird packets that don't match the above.
#

$IPTABLES -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT INPUT packet died: "

#
# 4.1.5 FORWARD chain
#

#
# Bad TCP packets we don't want
#

$IPTABLES -A FORWARD -p tcp -j bad_tcp_packets

#
# Accept the packets we actually want to forward
#

$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

#
# Log weird packets that don't match the above.
#

$IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT FORWARD packet died: "

#
# 4.1.6 OUTPUT chain
#

#
# Bad TCP packets we don't want.
#

$IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets

#
# Special OUTPUT rules to decide which IP's to allow.
#

$IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT

#
# Log weird packets that don't match the above.
#

$IPTABLES -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT OUTPUT packet died: "

######
# 4.2 nat table
#

#
# 4.2.1 Set policies
#

#
# 4.2.2 Create user specified chains
#

#
# 4.2.3 Create content in user specified chains
#

#
# 4.2.4 PREROUTING chain
#

#
# 4.2.5 POSTROUTING chain
#

#
# Enable simple IP Forwarding and Network Address Translation
#

$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP

#
# 4.2.6 OUTPUT chain
#

######
# 4.3 mangle table
#

#
# 4.3.1 Set policies
#

#
# 4.3.2 Create user specified chains
#

#
# 4.3.3 Create content in user specified chains
#

#
# 4.3.4 PREROUTING chain
#

#
# 4.3.5 INPUT chain
#

#
# 4.3.6 FORWARD chain
#

#
# 4.3.7 OUTPUT chain
#

#
# 4.3.8 POSTROUTING chain
#

I.2. ��
rc.DMZ.firewall

#!/bin/sh
#
# rc.DMZ.firewall - DMZ IP Firewall script for Linux 2.4.x and iptables
#
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

###########################################################################
#
# 1. Configuration options.
#

#
# 1.1 Internet Configuration.
#

INET_IP="194.236.50.152"
HTTP_IP="194.236.50.153"
DNS_IP="194.236.50.154"
INET_IFACE="eth0"

#
# 1.1.1 DHCP
#

#
# 1.1.2 PPPoE
#

#
# 1.2 Local Area Network configuration.
#
# your LAN's IP range and localhost IP. /24 means to only use the first 24
# bits of the 32 bit IP address. the same as netmask 255.255.255.0
#

LAN_IP="192.168.0.1"
LAN_IFACE="eth1"

#
# 1.3 DMZ Configuration.
#

DMZ_HTTP_IP="192.168.1.2"
DMZ_DNS_IP="192.168.1.3"
DMZ_IP="192.168.1.1"
DMZ_IFACE="eth2"

#
# 1.4 Localhost Configuration.
#

LO_IFACE="lo"
LO_IP="127.0.0.1"

#
# 1.5 IPTables Configuration.
#

IPTABLES="/usr/sbin/iptables"

#
# 1.6 Other Configuration.
#

###########################################################################
#
# 2. Module loading.
#

#
# Needed to initially load modules
#
/sbin/depmod -a



#
# 2.1 Required modules
#

/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_mangle
/sbin/modprobe iptable_nat
/sbin/modprobe ipt_LOG
/sbin/modprobe ipt_limit
/sbin/modprobe ipt_state

#
# 2.2 Non-Required modules
#

#/sbin/modprobe ipt_owner
#/sbin/modprobe ipt_REJECT
#/sbin/modprobe ipt_MASQUERADE
#/sbin/modprobe ip_conntrack_ftp
#/sbin/modprobe ip_conntrack_irc
#/sbin/modprobe ip_nat_ftp
#/sbin/modprobe ip_nat_irc

###########################################################################
#
# 3. /proc set up.
#

#
# 3.1 Required proc configuration
#

echo "1" > /proc/sys/net/ipv4/ip_forward

#
# 3.2 Non-Required proc configuration
#

#echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
#echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr

###########################################################################
#
# 4. rules set up.
#

######
# 4.1 Filter table
#

#
# 4.1.1 Set policies
#

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

#
# 4.1.2 Create userspecified chains
#

#
# Create chain for bad tcp packets
#

$IPTABLES -N bad_tcp_packets

#
# Create separate chains for ICMP, TCP and UDP to traverse
#

$IPTABLES -N allowed
$IPTABLES -N icmp_packets

#
# 4.1.3 Create content in userspecified chains
#

#
# bad_tcp_packets chain
#

$IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \
--log-prefix "New not syn:"
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

#
# allowed chain
#

$IPTABLES -A allowed -p TCP --syn -j ACCEPT
$IPTABLES -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A allowed -p TCP -j DROP

#
# ICMP rules
#

# Changed rules totally
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

#
# 4.1.4 INPUT chain
#

#
# Bad TCP packets we don't want
#

$IPTABLES -A INPUT -p tcp -j bad_tcp_packets

#
# Packets from the Internet to this box
#

$IPTABLES -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets

#
# Packets from LAN, DMZ or LOCALHOST
#

#
# From DMZ Interface to DMZ firewall IP
#

$IPTABLES -A INPUT -p ALL -i $DMZ_IFACE -d $DMZ_IP -j ACCEPT

#
# From LAN Interface to LAN firewall IP
#

$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -d $LAN_IP -j ACCEPT

#
# From Localhost interface to Localhost IP's
#

$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LO_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LAN_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $INET_IP -j ACCEPT

#
# Special rule for DHCP requests from LAN, which are not caught properly
# otherwise.
#

$IPTABLES -A INPUT -p UDP -i $LAN_IFACE --dport 67 --sport 68 -j ACCEPT

#
# All established and related packets incoming from the internet to the
# firewall
#

$IPTABLES -A INPUT -p ALL -d $INET_IP -m state --state ESTABLISHED,RELATED \
-j ACCEPT

#
# In Microsoft Networks you will be swamped by broadcasts. These lines
# will prevent them from showing up in the logs.
#

#$IPTABLES -A INPUT -p UDP -i $INET_IFACE -d $INET_BROADCAST \
#--destination-port 135:139 -j DROP

#
# If we get DHCP requests from the Outside of our network, our logs will
# be swamped as well. This rule will block them from getting logged.
#

#$IPTABLES -A INPUT -p UDP -i $INET_IFACE -d 255.255.255.255 \
#--destination-port 67:68 -j DROP

#
# If you have a Microsoft Network on the outside of your firewall, you may
# also get flooded by Multicasts. We drop them so we do not get flooded by
# logs
#

#$IPTABLES -A INPUT -i $INET_IFACE -d 224.0.0.0/8 -j DROP

#
# Log weird packets that don't match the above.
#

$IPTABLES -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT INPUT packet died: "

#
# 4.1.5 FORWARD chain
#

#
# Bad TCP packets we don't want
#

$IPTABLES -A FORWARD -p tcp -j bad_tcp_packets


#
# DMZ section
#
# General rules
#

$IPTABLES -A FORWARD -i $DMZ_IFACE -o $INET_IFACE -j ACCEPT
$IPTABLES -A FORWARD -i $INET_IFACE -o $DMZ_IFACE -m state \
--state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $LAN_IFACE -o $DMZ_IFACE -j ACCEPT
$IPTABLES -A FORWARD -i $DMZ_IFACE -o $LAN_IFACE -m state \
--state ESTABLISHED,RELATED -j ACCEPT

#
# HTTP server
#

$IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_HTTP_IP \
--dport 80 -j allowed
$IPTABLES -A FORWARD -p ICMP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_HTTP_IP \
-j icmp_packets

#
# DNS server
#

$IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP \
--dport 53 -j allowed
$IPTABLES -A FORWARD -p UDP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP \
--dport 53 -j ACCEPT
$IPTABLES -A FORWARD -p ICMP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP \
-j icmp_packets

#
# LAN section
#

$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

#
# Log weird packets that don't match the above.
#

$IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT FORWARD packet died: "

#
# 4.1.6 OUTPUT chain
#

#
# Bad TCP packets we don't want.
#

$IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets

#
# Special OUTPUT rules to decide which IP's to allow.
#

$IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT

#
# Log weird packets that don't match the above.
#

$IPTABLES -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT OUTPUT packet died: "

######
# 4.2 nat table
#

#
# 4.2.1 Set policies
#

#
# 4.2.2 Create user specified chains
#

#
# 4.2.3 Create content in user specified chains
#

#
# 4.2.4 PREROUTING chain
#

$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $HTTP_IP --dport 80 \
-j DNAT --to-destination $DMZ_HTTP_IP
$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $DNS_IP --dport 53 \
-j DNAT --to-destination $DMZ_DNS_IP
$IPTABLES -t nat -A PREROUTING -p UDP -i $INET_IFACE -d $DNS_IP --dport 53 \
-j DNAT --to-destination $DMZ_DNS_IP

#
# 4.2.5 POSTROUTING chain
#

#
# Enable simple IP Forwarding and Network Address Translation
#

$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP

#
# 4.2.6 OUTPUT chain
#

######
# 4.3 mangle table
#

#
# 4.3.1 Set policies
#

#
# 4.3.2 Create user specified chains
#

#
# 4.3.3 Create content in user specified chains
#

#
# 4.3.4 PREROUTING chain
#

#
# 4.3.5 INPUT chain
#

#
# 4.3.6 FORWARD chain
#

#
# 4.3.7 OUTPUT chain
#

#
# 4.3.8 POSTROUTING chain
#

I.3. ��
rc.UTIN.firewall

#!/bin/sh
#
# rc.firewall - UTIN Firewall script for Linux 2.4.x and iptables
#
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

###########################################################################
#
# 1. Configuration options.
#

#
# 1.1 Internet Configuration.
#

INET_IP="194.236.50.155"
INET_IFACE="eth0"
INET_BROADCAST="194.236.50.255"

#
# 1.1.1 DHCP
#

#
# 1.1.2 PPPoE
#

#
# 1.2 Local Area Network configuration.
#
# your LAN's IP range and localhost IP. /24 means to only use the first 24
# bits of the 32 bit IP address. the same as netmask 255.255.255.0
#

LAN_IP="192.168.0.2"
LAN_IP_RANGE="192.168.0.0/16"
LAN_IFACE="eth1"

#
# 1.3 DMZ Configuration.
#

#
# 1.4 Localhost Configuration.
#

LO_IFACE="lo"
LO_IP="127.0.0.1"

#
# 1.5 IPTables Configuration.
#

IPTABLES="/usr/sbin/iptables"

#
# 1.6 Other Configuration.
#

###########################################################################
#
# 2. Module loading.
#

#
# Needed to initially load modules
#

/sbin/depmod -a

#
# 2.1 Required modules
#

/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_mangle
/sbin/modprobe iptable_nat
/sbin/modprobe ipt_LOG
/sbin/modprobe ipt_limit
/sbin/modprobe ipt_state

#
# 2.2 Non-Required modules
#

#/sbin/modprobe ipt_owner
#/sbin/modprobe ipt_REJECT
#/sbin/modprobe ipt_MASQUERADE
#/sbin/modprobe ip_conntrack_ftp
#/sbin/modprobe ip_conntrack_irc
#/sbin/modprobe ip_nat_ftp
#/sbin/modprobe ip_nat_irc

###########################################################################
#
# 3. /proc set up.
#

#
# 3.1 Required proc configuration
#

echo "1" > /proc/sys/net/ipv4/ip_forward

#
# 3.2 Non-Required proc configuration
#

#echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
#echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr

###########################################################################
#
# 4. rules set up.
#

######
# 4.1 Filter table
#

#
# 4.1.1 Set policies
#

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

#
# 4.1.2 Create userspecified chains
#

#
# Create chain for bad tcp packets
#

$IPTABLES -N bad_tcp_packets

#
# Create separate chains for ICMP, TCP and UDP to traverse
#

$IPTABLES -N allowed
$IPTABLES -N tcp_packets
$IPTABLES -N udp_packets
$IPTABLES -N icmp_packets

#
# 4.1.3 Create content in userspecified chains
#

#
# bad_tcp_packets chain
#

$IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \
--log-prefix "New not syn:"
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

#
# allowed chain
#

$IPTABLES -A allowed -p TCP --syn -j ACCEPT
$IPTABLES -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A allowed -p TCP -j DROP

#
# TCP rules
#

$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 21 -j allowed
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 22 -j allowed
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 80 -j allowed
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 113 -j allowed

#
# UDP ports
#

#$IPTABLES -A udp_packets -p UDP -s 0/0 --source-port 53 -j ACCEPT
#$IPTABLES -A udp_packets -p UDP -s 0/0 --source-port 123 -j ACCEPT
$IPTABLES -A udp_packets -p UDP -s 0/0 --source-port 2074 -j ACCEPT
$IPTABLES -A udp_packets -p UDP -s 0/0 --source-port 4000 -j ACCEPT

#
# In Microsoft Networks you will be swamped by broadcasts. These lines
# will prevent them from showing up in the logs.
#

#$IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d $INET_BROADCAST \
#--destination-port 135:139 -j DROP

#
# If we get DHCP requests from the Outside of our network, our logs will
# be swamped as well. This rule will block them from getting logged.
#

#$IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d 255.255.255.255 \
#--destination-port 67:68 -j DROP

#
# ICMP rules
#

$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

#
# 4.1.4 INPUT chain
#

#
# Bad TCP packets we don't want.
#

$IPTABLES -A INPUT -p tcp -j bad_tcp_packets

#
# Rules for special networks not part of the Internet
#

$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LO_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LAN_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $INET_IP -j ACCEPT

#
# Rules for incoming packets from anywhere.
#

$IPTABLES -A INPUT -p ALL -d $INET_IP -m state --state ESTABLISHED,RELATED \
-j ACCEPT
$IPTABLES -A INPUT -p TCP -j tcp_packets
$IPTABLES -A INPUT -p UDP -j udp_packets
$IPTABLES -A INPUT -p ICMP -j icmp_packets

#
# If you have a Microsoft Network on the outside of your firewall, you may
# also get flooded by Multicasts. We drop them so we do not get flooded by
# logs
#

#$IPTABLES -A INPUT -i $INET_IFACE -d 224.0.0.0/8 -j DROP

#
# Log weird packets that don't match the above.
#

$IPTABLES -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT INPUT packet died: "

#
# 4.1.5 FORWARD chain
#

#
# Bad TCP packets we don't want
#

$IPTABLES -A FORWARD -p tcp -j bad_tcp_packets

#
# Accept the packets we actually want to forward
#

$IPTABLES -A FORWARD -p tcp --dport 21 -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -p tcp --dport 80 -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -p tcp --dport 110 -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

#
# Log weird packets that don't match the above.
#

$IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT FORWARD packet died: "

#
# 4.1.6 OUTPUT chain
#

#
# Bad TCP packets we don't want.
#

$IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets

#
# Special OUTPUT rules to decide which IP's to allow.
#

$IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT

#
# Log weird packets that don't match the above.
#

$IPTABLES -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT OUTPUT packet died: "

######
# 4.2 nat table
#

#
# 4.2.1 Set policies
#

#
# 4.2.2 Create user specified chains
#

#
# 4.2.3 Create content in user specified chains
#

#
# 4.2.4 PREROUTING chain
#

#
# 4.2.5 POSTROUTING chain
#

#
# Enable simple IP Forwarding and Network Address Translation
#

$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP

#
# 4.2.6 OUTPUT chain
#

######
# 4.3 mangle table
#

#
# 4.3.1 Set policies
#

#
# 4.3.2 Create user specified chains
#

#
# 4.3.3 Create content in user specified chains
#

#
# 4.3.4 PREROUTING chain
#

#
# 4.3.5 INPUT chain
#

#
# 4.3.6 FORWARD chain
#

#
# 4.3.7 OUTPUT chain
#

#
# 4.3.8 POSTROUTING chain
#

I.4. ��
rc.DHCP.firewall

#!/bin/sh
#
# rc.firewall - DHCP IP Firewall script for Linux 2.4.x and iptables
#
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

###########################################################################
#
# 1. Configuration options.
#

#
# 1.1 Internet Configuration.
#

INET_IFACE="eth0"

#
# 1.1.1 DHCP
#

#
# Information pertaining to DHCP over the Internet, if needed.
#
# Set DHCP variable to no if you don't get IP from DHCP. If you get DHCP
# over the Internet set this variable to yes, and set up the proper IP
# address for the DHCP server in the DHCP_SERVER variable.
#

DHCP="no"
DHCP_SERVER="195.22.90.65"

#
# 1.1.2 PPPoE
#

# Configuration options pertaining to PPPoE.
#
# If you have problem with your PPPoE connection, such as large mails not
# getting through while small mail get through properly etc, you may set
# this option to "yes" which may fix the problem. This option will set a
# rule in the PREROUTING chain of the mangle table which will clamp
# (resize) all routed packets to PMTU (Path Maximum Transmit Unit).
#
# Note that it is better to set this up in the PPPoE package itself, since
# the PPPoE configuration option will give less overhead.
#

PPPOE_PMTU="no"

#
# 1.2 Local Area Network configuration.
#
# your LAN's IP range and localhost IP. /24 means to only use the first 24
# bits of the 32 bit IP address. the same as netmask 255.255.255.0
#

LAN_IP="192.168.0.2"
LAN_IP_RANGE="192.168.0.0/16"
LAN_IFACE="eth1"

#
# 1.3 DMZ Configuration.
#

#
# 1.4 Localhost Configuration.
#

LO_IFACE="lo"
LO_IP="127.0.0.1"

#
# 1.5 IPTables Configuration.
#

IPTABLES="/usr/sbin/iptables"

#
# 1.6 Other Configuration.
#

###########################################################################
#
# 2. Module loading.
#

#
# Needed to initially load modules
#

/sbin/depmod -a

#
# 2.1 Required modules
#

/sbin/modprobe ip_conntrack
/sbin/modprobe ip_tables
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_mangle
/sbin/modprobe iptable_nat
/sbin/modprobe ipt_LOG
/sbin/modprobe ipt_limit
/sbin/modprobe ipt_MASQUERADE

#
# 2.2 Non-Required modules
#

#/sbin/modprobe ipt_owner
#/sbin/modprobe ipt_REJECT
#/sbin/modprobe ip_conntrack_ftp
#/sbin/modprobe ip_conntrack_irc
#/sbin/modprobe ip_nat_ftp
#/sbin/modprobe ip_nat_irc

###########################################################################
#
# 3. /proc set up.
#

#
# 3.1 Required proc configuration
#

echo "1" > /proc/sys/net/ipv4/ip_forward

#
# 3.2 Non-Required proc configuration
#

#echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
#echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr

###########################################################################
#
# 4. rules set up.
#

######
# 4.1 Filter table
#

#
# 4.1.1 Set policies
#

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

#
# 4.1.2 Create userspecified chains
#

#
# Create chain for bad tcp packets
#

$IPTABLES -N bad_tcp_packets

#
# Create separate chains for ICMP, TCP and UDP to traverse
#

$IPTABLES -N allowed
$IPTABLES -N tcp_packets
$IPTABLES -N udp_packets
$IPTABLES -N icmp_packets

#
# 4.1.3 Create content in userspecified chains
#

#
# bad_tcp_packets chain
#

$IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \
--log-prefix "New not syn:"
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

#
# allowed chain
#

$IPTABLES -A allowed -p TCP --syn -j ACCEPT
$IPTABLES -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A allowed -p TCP -j DROP

#
# TCP rules
#

$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 21 -j allowed
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 22 -j allowed
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 80 -j allowed
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 113 -j allowed

#
# UDP ports
#

$IPTABLES -A udp_packets -p UDP -s 0/0 --source-port 53 -j ACCEPT
if [ $DHCP == "yes" ] ; then
 $IPTABLES -A udp_packets -p UDP -s $DHCP_SERVER --sport 67 \
 --dport 68 -j ACCEPT
fi

#$IPTABLES -A udp_packets -p UDP -s 0/0 --source-port 53 -j ACCEPT
#$IPTABLES -A udp_packets -p UDP -s 0/0 --source-port 123 -j ACCEPT
$IPTABLES -A udp_packets -p UDP -s 0/0 --source-port 2074 -j ACCEPT
$IPTABLES -A udp_packets -p UDP -s 0/0 --source-port 4000 -j ACCEPT

#
# In Microsoft Networks you will be swamped by broadcasts. These lines
# will prevent them from showing up in the logs.
#

#$IPTABLES -A udp_packets -p UDP -i $INET_IFACE \
#--destination-port 135:139 -j DROP

#
# If we get DHCP requests from the Outside of our network, our logs will
# be swamped as well. This rule will block them from getting logged.
#

#$IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d 255.255.255.255 \
#--destination-port 67:68 -j DROP

#
# ICMP rules
#

$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

#
# 4.1.4 INPUT chain
#

#
# Bad TCP packets we don't want.
#

$IPTABLES -A INPUT -p tcp -j bad_tcp_packets

#
# Rules for special networks not part of the Internet
#

$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s $LAN_IP_RANGE -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -j ACCEPT

#
# Special rule for DHCP requests from LAN, which are not caught properly 
# otherwise.
#

$IPTABLES -A INPUT -p UDP -i $LAN_IFACE --dport 67 --sport 68 -j ACCEPT

#
# Rules for incoming packets from the internet.
#

$IPTABLES -A INPUT -p ALL -i $INET_IFACE -m state --state ESTABLISHED,RELATED \
-j ACCEPT
$IPTABLES -A INPUT -p TCP -i $INET_IFACE -j tcp_packets
$IPTABLES -A INPUT -p UDP -i $INET_IFACE -j udp_packets
$IPTABLES -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets

#
# If you have a Microsoft Network on the outside of your firewall, you may
# also get flooded by Multicasts. We drop them so we do not get flooded by
# logs
#

#$IPTABLES -A INPUT -i $INET_IFACE -d 224.0.0.0/8 -j DROP

#
# Log weird packets that don't match the above.
#

$IPTABLES -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT INPUT packet died: "

#
# 4.1.5 FORWARD chain
#

#
# Bad TCP packets we don't want
#

$IPTABLES -A FORWARD -p tcp -j bad_tcp_packets

#
# Accept the packets we actually want to forward
#

$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

#
# Log weird packets that don't match the above.
#

$IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT FORWARD packet died: "

#
# 4.1.6 OUTPUT chain
#

#
# Bad TCP packets we don't want.
#

$IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets

#
# Special OUTPUT rules to decide which IP's to allow.
#

$IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -o $INET_IFACE -j ACCEPT

#
# Log weird packets that don't match the above.
#

$IPTABLES -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT OUTPUT packet died: "

######
# 4.2 nat table
#

#
# 4.2.1 Set policies
#

#
# 4.2.2 Create user specified chains
#

#
# 4.2.3 Create content in user specified chains
#

#
# 4.2.4 PREROUTING chain
#

#
# 4.2.5 POSTROUTING chain
#

if [ $PPPOE_PMTU == "yes" ] ; then
 $IPTABLES -t nat -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN \
 -j TCPMSS --clamp-mss-to-pmtu
fi
$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j MASQUERADE

#
# 4.2.6 OUTPUT chain
#

######
# 4.3 mangle table
#

#
# 4.3.1 Set policies
#

#
# 4.3.2 Create user specified chains
#

#
# 4.3.3 Create content in user specified chains
#

#
# 4.3.4 PREROUTING chain
#

#
# 4.3.5 INPUT chain
#

#
# 4.3.6 FORWARD chain
#

#
# 4.3.7 OUTPUT chain
#

#
# 4.3.8 POSTROUTING chain
#

I.5. ��
rc.flush-iptables

#!/bin/sh
# 
# rc.flush-iptables - Resets iptables to default values. 
# 
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA

#
# Configurations
#
IPTABLES="/usr/sbin/iptables"

#
# reset the default policies in the filter table.
#
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -P OUTPUT ACCEPT

#
# reset the default policies in the nat table.
#
$IPTABLES -t nat -P PREROUTING ACCEPT
$IPTABLES -t nat -P POSTROUTING ACCEPT
$IPTABLES -t nat -P OUTPUT ACCEPT

#
# reset the default policies in the mangle table.
#
$IPTABLES -t mangle -P PREROUTING ACCEPT
$IPTABLES -t mangle -P OUTPUT ACCEPT

#
# flush all the rules in the filter and nat tables.
#
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -t mangle -F
#
# erase all chains that's not default in filter and nat table.
#
$IPTABLES -X
$IPTABLES -t nat -X
$IPTABLES -t mangle -X

I.6. ��
rc.test-iptables

#!/bin/bash
#
# rc.test-iptables - test script for iptables chains and tables.
#
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

#
# Filter table, all chains
#
iptables -t filter -A INPUT -p icmp --icmp-type echo-request \
-j LOG --log-prefix="filter INPUT:"
iptables -t filter -A INPUT -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="filter INPUT:"
iptables -t filter -A OUTPUT -p icmp --icmp-type echo-request \
-j LOG --log-prefix="filter OUTPUT:"
iptables -t filter -A OUTPUT -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="filter OUTPUT:"
iptables -t filter -A FORWARD -p icmp --icmp-type echo-request \
-j LOG --log-prefix="filter FORWARD:"
iptables -t filter -A FORWARD -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="filter FORWARD:"

#
# NAT table, all chains except OUTPUT which don't work.
#
iptables -t nat -A PREROUTING -p icmp --icmp-type echo-request \
-j LOG --log-prefix="nat PREROUTING:"
iptables -t nat -A PREROUTING -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="nat PREROUTING:"
iptables -t nat -A POSTROUTING -p icmp --icmp-type echo-request \
-j LOG --log-prefix="nat POSTROUTING:"
iptables -t nat -A POSTROUTING -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="nat POSTROUTING:"
iptables -t nat -A OUTPUT -p icmp --icmp-type echo-request \
-j LOG --log-prefix="nat OUTPUT:"
iptables -t nat -A OUTPUT -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="nat OUTPUT:"

#
# Mangle table, all chains
#
iptables -t mangle -A PREROUTING -p icmp --icmp-type echo-request \
-j LOG --log-prefix="mangle PREROUTING:"
iptables -t mangle -A PREROUTING -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="mangle PREROUTING:"
iptables -t mangle -I FORWARD 1 -p icmp --icmp-type echo-request \
-j LOG --log-prefix="mangle FORWARD:"
iptables -t mangle -I FORWARD 1 -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="mangle FORWARD:"
iptables -t mangle -I INPUT 1 -p icmp --icmp-type echo-request \
-j LOG --log-prefix="mangle INPUT:"
iptables -t mangle -I INPUT 1 -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="mangle INPUT:"
iptables -t mangle -A OUTPUT -p icmp --icmp-type echo-request \
-j LOG --log-prefix="mangle OUTPUT:"
iptables -t mangle -A OUTPUT -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="mangle OUTPUT:"
iptables -t mangle -I POSTROUTING 1 -p icmp --icmp-type echo-request \
-j LOG --log-prefix="mangle POSTROUTING:"
iptables -t mangle -I POSTROUTING 1 -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="mangle POSTROUTING:"

Источник

Время на прочтение
6 мин

Количество просмотров 16K

Схема работы Iptables:

Iptables как с ним работать

Iptables — это мощный инструмент управления сетью в Linux, который позволяет администраторам управлять входящими и исходящими пакетами данных. Это основной инструмент для настройки межсетевых экранов в системах Linux.

Введение в Iptables

Iptables работает путем проверки пакетов данных на соответствие определенным критериям и выполнения заданных действий, если пакеты соответствуют этим критериям. Эти критерии и действия определяются в таблицах, которые состоят из набора правил.

В Iptables есть четыре основные таблицы:

Filter — это основная таблица, используемая для фильтрации пакетов.
NAT — эта таблица используется для настройки NAT (Network Address Translation).
Mangle — эта таблица используется для специальной обработки пакетов.
Raw — эта таблица используется для обхода системы отслеживания состояний.

Каждая таблица состоит из набора цепочек. Цепочки — это последовательности правил, которые применяются к пакетам. В Iptables есть три встроенные цепочки:

INPUT — эта цепочка применяется к пакетам, которые предназначены для самой системы.
FORWARD — эта цепочка применяется к пакетам, которые проходят через систему.
OUTPUT — эта цепочка применяется к пакетам, которые исходят из системы.

Базовые команды Iptables

Просмотр текущих правил

Чтобы просмотреть текущие правила, используйте команду iptables -L. Это покажет все правила в таблице filter. Чтобы просмотреть правила в другой таблице, используйте флаг -t, например, iptables -t nat -L.

Добавление новых правил

Чтобы добавить новое правило, используйте команду iptables -A. Например, чтобы заблокировать весь входящий трафик от IP-адреса 192.168.0.100, вы можете использовать следующую команду:

iptables -A INPUT -s 192.168.0.100 -j DROP

В этой команде -A INPUT добавляет новое правило в цепочку INPUT, -s 192.168.0.100 определяет исходный IP-адрес, а -j DROP указывает, что все пакеты, соответствующие этому правилу, должны быть отброшены.

Удаление правил

Чтобы удалить правило, вам нужно знать его номер в цепочке. Вы можете узнать номера правил, используя команду iptables -L --line-numbers. Затем вы можете удалить правило, используя команду iptables -D и номер правила. Например, чтобы удалить первое правило в цепочке INPUT, вы можете использовать следующую команду:

iptables -D INPUT 1

Изменение дефолтного политики

Вы можете изменить дефолтную политику для цепочки, используя команду iptables -P. Например, чтобы отклонить все входящие пакеты по умолчанию, вы можете использовать следующую команду:

iptables -P INPUT DROP

Сохранение и восстановление правил

По умолчанию, правила iptables не сохраняются после перезагрузки системы. Чтобы сохранить текущие правила, вы можете использовать команду iptables-save. Это выведет текущие правила в формате, который можно использовать для восстановления с помощью команды iptables-restore.

iptables-save > /path/to/iptables/rules

Затем, чтобы восстановить правила, вы можете использовать следующую команду:

iptables-restore < /path/to/iptables/rules

Примеры использования Iptables

Блокировка IP-адреса

Чтобы заблокировать весь трафик от определенного IP-адреса, вы можете использовать следующую команду:

iptables -A INPUT -s 192.168.0.100 -j DROP

Открытие порта для входящего трафика

Чтобы открыть порт для входящего трафика, вы можете использовать следующую команду:

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

В этой команде -p tcp указывает на протокол (в данном случае TCP), --dport 80 указывает на порт (в данном случае 80), а -j ACCEPT указывает, что все пакеты, соответствующие этому правилу, должны быть приняты.

Настройка простого межсетевого экрана

Вы можете использовать iptables для настройки простого межсетевого экрана. Например, вы можете разрешить весь исходящий трафик, разрешить входящий трафик только на определенные порты и отклонить все остальные входящие пакеты.

iptables -A OUTPUT -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -P INPUT DROP

В этом примере разрешен весь исходящий трафик, а входящий трафик разрешен только на порты 22 (SSH), 80 (HTTP) и 443 (HTTPS). Все остальные входящие пакеты отклоняются.

Расширенное использование Iptables

Логирование

Iptables предоставляет возможность логирования пакетов, что может быть полезно для отладки и мониторинга. Для включения логирования используйте цель LOG. Например, чтобы залогировать все отброшенные пакеты, можно использовать следующую команду:

iptables -A INPUT -j LOG --log-prefix "Dropped Packet: " iptables -A INPUT -j DROP

Здесь --log-prefix "Dropped Packet: " добавляет указанный префикс к каждому лог-сообщению, что упрощает фильтрацию и анализ логов.

Создание пользовательских цепочек

Iptables позволяет создавать пользовательские цепочки для более гибкого управления правилами. Например, вы можете создать цепочку для обработки всего трафика от определенного IP-адреса:

iptables -N MY_CHAIN iptables -A MY_CHAIN -s 192.168.0.100 -j DROP iptables -A INPUT -j MY_CHAIN

В этом примере команда -N MY_CHAIN создает новую цепочку с именем MY_CHAIN. Затем добавляется правило, которое отбрасывает все пакеты от 192.168.0.100. Наконец, цепочка MY_CHAIN добавляется в цепочку INPUT, что означает, что все входящие пакеты будут также проходить через цепочку MY_CHAIN.

Использование состояний пакетов

Iptables может отслеживать состояние пакетов, что позволяет создавать более сложные правила. Например, вы можете разрешить только входящие пакеты, которые являются частью уже установленного соединения:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

В этом примере -m state указывает на использование модуля состояний, а --state ESTABLISHED,RELATED указывает, что правило применяется только к пакетам, которые являются частью уже установленного или связанного соединения.

Использование Iptables для создания VPN

Iptables также может быть использован для создания VPN (Virtual Private Network). Это может быть полезно для создания безопасного соединения между удаленными системами. Например, вы можете использовать iptables для настройки IPsec VPN, используя модуль «policy» для определения правил обработки трафика.

iptables -A INPUT -m policy --dir in --pol ipsec -j ACCEPT iptables -A OUTPUT -m policy --dir out --pol ipsec -j ACCEPT

В этом примере -m policy указывает на использование модуля «policy», --dir in и --dir out указывают на направление трафика, а --pol ipsec указывает на использование IPsec политики.

Использование Iptables для ограничения скорости

Iptables также может быть использован для ограничения скорости сетевого трафика, что может быть полезно для управления пропускной способностью. Для этого можно использовать модуль «limit». Например, вы можете ограничить количество новых SSH-соединений до 3 в минуту следующим образом:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min -j ACCEPT

В этом примере -m limit --limit 3/min указывает на ограничение скорости, а остальная часть команды определяет, что она применяется к новым SSH-соединениям.

Использование Iptables для редиректа трафика

Iptables может быть использован для редиректа трафика, что может быть полезно для перенаправления трафика на другой порт или сервер. Например, вы можете перенаправить весь входящий трафик на порт 80 на порт 8080 следующим образом:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

В этом примере -t nat указывает на использование таблицы NAT, -A PREROUTING добавляет правило в цепочку PREROUTING, --dport 80 указывает на исходный порт, а --to-port 8080 указывает на порт назначения.

Iptables — это мощный и гибкий инструмент, который может быть использован для решения множества задач управления сетью. Однако, как и любой мощный инструмент, он требует тщательного понимания и практики для эффективного использования.

Заключение

Iptables является мощным и гибким инструментом для управления сетью в Linux. Он предлагает широкий спектр функций, включая фильтрацию пакетов, NAT, логирование и многое другое. Однако, несмотря на его мощь, iptables может быть сложным для новичков. Надеюсь, эта статья помогла вам разобраться в основах работы с iptables и дала вам основу для дальнейшего изучения этого мощного инструмента.

Источник

Состояние перевода: На этой странице представлен перевод статьи iptables. Дата последней синхронизации: 10 июля 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

iptables — утилита командной строки для настройки встроенного в ядро Linux межсетевого экрана, разработанного в рамках проекта Netfilter. Термином iptables также часто называют сам межсетевой экран в ядре. Настройка экрана выполняется либо напрямую с помощью iptables, либо через один из фронтендов, консольных или графических. iptables работает с протоколом IPv4, для IPv6 разработана утилита ip6tables. В основном их синтаксис совпадает, но некоторые специфичные для протоколов опции различаются.

Примечание: Фреймворк iptables постепенно выходит из употребления; более современная замена — nftables, в котором предусмотрен слой совместимости.

Установка

Стандартное ядро Arch Linux скомпилировано с поддержкой iptables. Необходимо лишь установить набор пользовательских утилит, которые собраны в пакет iptables. Поскольку данный пакет является косвенной зависимостью мета-пакета base, то он по умолчанию должен быть установлен в системе.

Фронтенды

Консольные

Arno’s firewall — безопасный межсетевой экран как для одиночной машины, так и для разрозненной сети. Лёгок в настройке, удобен в использовании, хорошо кастомизируется. Поддерживает: NAT и SNAT, проброс портов, ADSL ethernet-модемы со статическими и динамическими IP-адресами, фильтрацию MAC-адресов, обнаружение скрытого сканирования портов, DMZ и DMZ-2-LAN пересылку, защиту от SYN/ICMP флуда, обширное логирование с временными ограничениями для предотвращения засорения логов, все IP-протоколы и технологии VPN вроде IPsec, плагины для расширения функциональности.

https://rocky.eld.leidenuniv.nl/ || arno-iptables-firewall^AUR

ferm — инструмент для обслуживания комплексных межсетевых экранов, помогающий избежать необходимости переписывать сложные правила снова и снова. Позволяет сохранить целый набор правил в одном файле и загрузить его всего одной командой. Настройка экрана производится посредством специального языка, наподобие языка программирования, с помощью уровней и списков.

http://ferm.foo-projects.org/ || ferm

FireHOL — не только программа для создания межсетевого экрана, но и специальный язык для задания его настроек. Делает даже тонкую настройку экрана лёгкой — как вам бы и хотелось.

http://firehol.sourceforge.net/ || firehol^AUR

Firetable — инструмент для межсетевого экрана iptables. Каждый сетевой интерфейс настраивается отдельно в соответствии с собственным файлом настроек, синтаксис которого понятен и удобен.

https://gitlab.com/hsleisink/firetable || firetable^AUR

firewalld (firewall-cmd) — демон и консольный интерфейс для настройки сети, зональной политики и правил межсетевого экрана.

https://firewalld.org/ || firewalld

Shorewall — высокоуровневый инструмент для настройки Netfilter. Требования к экрану/шлюзу описываются посредством записей в наборе файлов настроек.

http://www.shorewall.net/ || shorewall^AUR

Uncomplicated Firewall — простой интерфейс для iptables.

https://launchpad.net/ufw || ufw

PeerGuardian (pglcmd) — ориентированное на приватность firewall-приложение. Занимается блокировкой входящих и исходящих подключений на основе огромного чёрного списка (тысячи или даже миллионы IP-диапазонов).

https://sourceforge.net/projects/peerguardian/ || pgl^AUR

Vuurmuur — мощный менеджер сетевого экрана. Лёгкая в освоении настройка, которая позволяет создавать как простые, так и сложные конфигурации межсетевого экрана. Для настройки есть графический интерфейс на основе ncurses, который позволяет осуществлять безопасное удалённое администрирование через SSH или консоль. Vuurmuur поддерживает ограничение трафика, имеет мощную систему мониторинга, которая позволяет администратору следить за логами, подключениями и использованием пропускной способности в режиме реального времени.

https://www.vuurmuur.org/ || vuurmuur^AUR

Графические

Firewall Builder — графический интерфейс для настройки и управления межсетевыми экранами, работает с iptables (netfilter), ipfilter, pf, ipfw, Cisco PIX (FWSM, ASA), а также с маршрутизаторами Cisco с поддержкой Extended ACL. Запускается на Linux, FreeBSD, OpenBSD, Windows и macOS, может управлять как локальными, так и удалёнными межсетевыми экранами.

https://fwbuilder.sourceforge.net/ || fwbuilder

firewalld (firewall-config) — демон и графический интерфейс для настройки сети, зональной политики и правил межсетевого экрана.

https://firewalld.org/ || firewalld

Gufw — графический GTK-интерфейс для ufw, который, в свою очередь, является интерфейсом командной строки для iptables (gufw–>ufw–>iptables), лёгкий и простой в использовании.

https://gufw.org/ || gufw

PeerGuardian GUI (pglgui) — ориентированное на приватность firewall-приложение. Занимается блокировкой входящих и исходящих подключений на основе огромного чёрного списка (тысячи или даже миллионы IP-диапазонов).

https://sourceforge.net/projects/peerguardian/ || pgl^AUR

Основные понятия

iptables используется для проверки, модификации, перенаправления и отбрасывания пакетов. Код для фильтрации пакетов IPv4 уже встроен в ядро и организован в виде набора таблиц, каждая из которых предназначена для конкретной цели. Таблица состоит из группы предопределённых цепочек, а те, в свою очередь, содержат правила, которые проверяются по очереди. Каждое правило состоит из критерия (набора условий) и действия (т.н. цели); действие применяется к пакету, подпадающему под критерий (т. е. если все условия выполнены). Если пакет достигает конца встроенной цепочки, в том числе пустой, то он отправляется дальше в соответствии с политикой цепочки. iptables — пользовательская утилита для работы с цепочками и правилами. Большинство пользователей находят IP-маршрутизацию Linux сложной и запутанной, однако на практике наиболее распространенные варианты использования (NAT и/или базовый межсетевой экран для интернета) являются значительно менее сложными.

Ключ к пониманию принципа работы iptables находится в этой блок-схеме. Слова в нижнем регистре в верхней части каждого блока являются именами таблиц, а слова в верхнем регистре – цепочками. Каждый IP-пакет, принятый на любом сетевом интерфейсе, проходит через эту блок-схему сверху вниз. Существует заблуждение, что пакеты, приходящие на внутренний интерфейс, обрабатываются как-то иначе нежели те, что приходят на интерфейс, подключённый к интернету. Пакеты на всех интерфейсах обрабатываются одинаково; это ваша задача написать правила, которые будут обрабатывать их по-разному. Некоторые пакеты предназначены для локальных процессов; они проходят по схеме от верхнего блока до блока <Local Process> (локальный процесс). В то же время локальный процесс сам может генерировать пакеты, и они начинают путешествие по схеме с блока <Local Process> и далее вниз. Подробное описание работы этой блок-схемы можно найти здесь.

В подавляющем большинстве случаев таблицы raw, mangle и security вам не понадобятся. На схеме ниже приведён упрощённый вариант прохождения пакета через iptables:

                               XXXXXXXXXXXXXXXXXX
                             XXX      Сеть      XXX
                               XXXXXXXXXXXXXXXXXX
                                       +
                                       |
                                       v
+---------------+             +-------------------+
|таблица: filter| <---+       |таблица: nat       |
|цепочка: INPUT |     |       |цепочка: PREROUTING|
+-------+-------+     |       +--------+----------+
        |             |                |
        v             |                v
[локальный процесс]   |         ***************          +----------------+
        |             +-------+  Маршрутизация  +------> |таблица: filter |
        v                       ***************          |цепочка: FORWARD|
 ***************                                         +-------+--------+
  Маршрутизация                                                  |
 ***************                                                 |
        |                                                        |
        v                       ***************                  |
+---------------+     +------>   Маршрутизация   <---------------+
|таблица: nat   |     |         ***************
|цепочка: OUTPUT|     |                +
+------+--------+     |                |
        |             |                v
        v             |      +---------------------+
+---------------+     |      | таблица: nat        |
|таблица: filter| +---+      | цепочка: POSTROUTING|
|цепочка: OUTPUT|            +---------+-----------+
+---------------+                      |
                                       v
                               XXXXXXXXXXXXXXXXXX
                             XXX      Сеть      XXX
                               XXXXXXXXXXXXXXXXXX

Таблицы

iptables содержит пять таблиц:

raw — используется только для настройки пакетов, поэтому они освобождаются от отслеживания.
filter — таблица по умолчанию; в ней сосредоточены все действия, типичные для межсетевых экранов.
nat — используется для преобразования сетевых адресов (например, проброс портов).
mangle — используется для специальных преобразований пакетов.
security — используется в сетевых правилах для Мандатного управления доступом (например, в SELinux – подробнее см. эту статью).

Скорее всего, вам потребуются только две из них: filter и nat. Остальные таблицы используются в сложных конфигурациях с несколькими маршрутизаторами и выходят за рамки данной статьи.

Цепочки

Таблицы состоят из цепочек, которые представляют собой набор правил, следующих друг за другом в определённом порядке. Таблица по умолчанию, filter, содержит три встроенные цепочки: INPUT, OUTPUT и FORWARD, которые, как видно из диаграммы, активируются в определённые моменты процесса фильтрации пакетов. Таблица nat включает стандартные цепочки PREROUTING, POSTROUTING и OUTPUT.

Описание стандартных цепочек других таблиц можно найти в руководстве iptables(8).

По умолчанию все цепочки пусты и не содержат каких-либо правил. Вы должны добавить правила в те цепочки, которые собираетесь использовать. У цепочек также задана политика по умолчанию — обычно ACCEPT, но её можно изменить на DROP, если вы хотите убедиться, что ни один пакет не проскочит мимо вашего набора правил. Тем не менее, политика по умолчанию применяется к пакету только после того, как он пройдёт через все существующие правила.

Вы можете добавить собственные цепочки для большей эффективности или удобства. Пример создания таких цепочек можно найти в статье Настройка межсетевого экрана.

Правила

Фильтрация пакетов основана на правилах. Каждое правило состоит из нескольких условий и действия-цели. Если пакет соответствует всем условиям, то к нему применяется указанное действие. Распространённые условия для проверки — на какой интерфейс пришёл пакет (например, eth0 или eth1), какого он типа (ICMP, TCP или UDP) или на какой порт направляется.

Цели указываются опцией -j/--jump. Цель может быть встроеной (built-in), целью-расширением (extension) или переходом на пользовательскую цепочку. Встроенные цели — ACCEPT, DROP, QUEUE и RETURN; цели-расширения, к примеру — REJECT и LOG. Если применяется встроенная цель, то участь пакета решается незамедлительно и обработка пакета в таблице прекращается. Если в качестве цели выбран переход на пользовательскую цепочку, то пакет проходит через неё, возвращается в исходную цепочку и продолжает со следующего после перехода правила. Цели-расширения могут быть завершающими (как встроенные) или незавершающими (как пользовательские цепочки). Подробнее см. iptables-extensions(8).

Прохождение по цепочке

Принятый на сетевом интерфейсе пакет проходит по цепочкам таблиц в порядке, изображённом на диаграмме. В первой точке маршрутизации (routing decision) принимается решение, направляется ли пакет на локальную машину (в таком случае пакет проходит через цепочку INPUT) или куда-то в другое место (в этом случае пакет проходит через цепочку FORWARD). Последующие точки маршрутизации определяют, на какой сетевой интерфейс направить исходящий пакет. В каждой цепочке по пути следования пакета последовательно проверяются все правила, и если пакет удовлетворяет условиям правила, то выполняется соответствующее действие-цель. Три наиболее частых цели – ACCEPT, DROP и переход на пользовательскую цепочку. В противоположность встроенным цепочкам, которые имеют цели по умолчанию, цепочки пользователя такой цели не имеют. Если не удовлетворены условия ни одного из правил пользовательской цепочки, пакет возвращается обратно в вызвавшую её цепочку, как показано здесь. Если в какое-то момент выполнились все условия цепочки с действием DROP, пакет немедленно отбрасывается и над ним более не производится никаких действий. Обратите, однако, внимание, что если пакет принят действием ACCEPT, он принимается только в текущей цепочке и в вышележащих цепочках в текущем стеке вызовов. Он не обрабатывается более той стандартной цепочкой, которая инициировала последовательность переходов, но продолжает проходить по цепочкам в других таблицах обычным образом.

Модули

Существует ряд модулей для расширения возможностей iptables, среди которых connlimit, conntrack, limit и recent. Эти модули добавляют новую функциональность в iptables, что позволяет создавать более сложные правила фильтрации.

Настройка и использование

iptables — служба systemd и запускается соответственно. Пакет iptables при установке добавляет пустой комплект правил /etc/iptables/iptables.rules, который будет загружен при первом запуске службы iptables.service. Как и прочие службы, службу iptables для добавления в автозапуск необходимо включить.

Правила iptables для IPv6 по умолчанию хранятся в файле /etc/iptables/ip6tables.rules, который используется службой ip6tables.service. Эту службу можно запустить так же, как и iptables.service.

После добавления правил посредством командной строки файл настроек не изменится автоматически — изменения необходимо сохранять командой:

# iptables-save -f /etc/iptables/iptables.rules

Если вы изменяли файл настроек вручную, то либо перезагрузите службу iptables, либо загрузите настройки вручную командой:

# iptables-restore /etc/iptables/iptables.rules

Из командной строки

Вывод текущих правил

Основная команда для вывода текущих правил — --list-rules/-S; её вывод похож на вывод утилиты iptables-save. Разница между ними в том, что по умолчанию последняя выводит правила из всех таблиц, в то время как iptables — только из таблицы filter.

Команда --list/-L принимает больше модификаторов и выводит более подробную информацию. Например, следующая команда позволяет проверить текущий набор правил и количество срабатываний каждого из них:

# iptables -nvL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Представленный выше вывод свидетельствует о том, что в таблице по умолчанию (filter) никакие правила не заданы и все пакеты пропускаются. Выбрать другую таблицу можно опцией -t.

Чтобы вывести номера строк при просмотре правил, запустите команду с опцией --line-numbers. Это бывает удобно для последующего редактирования правил в командной строке.

Сброс правил

Сбросить правила iptables можно следующими командами:

# iptables -F
# iptables -X
# iptables -t nat -F
# iptables -t nat -X
# iptables -t mangle -F
# iptables -t mangle -X
# iptables -t raw -F
# iptables -t raw -X
# iptables -t security -F
# iptables -t security -X
# iptables -P INPUT ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -P OUTPUT ACCEPT

Команда -F без аргументов просто очищает все цепочки в текущей таблице. Аналогично, команда -X удаляет все пустые пользовательские цепочки в таблице.

Отдельные цепочки могут быть очищены от правил или удалены указанием имени цепочки после команд -F и -X соответственно.

Редактирование правил

Редактирование правил подразумевает одно из следующих действий: добавление правила в конец цепочки (-A), вставка правила в конкретную позицию в цепочке (-I), замена (-R) и удаление (-D) существующего правила.

Примеры ниже приведены исходя из соображения, что компьютер не является маршрутизатором. Поэтому первым делом меняем политику цепочки FORWARD с ACCEPT на DROP:

# iptables -P FORWARD DROP

Важно: Этот раздел не претендует на роль руководства по защите серверов. Его назначение — научить синтаксису и принципам правил iptables. Изучите статью Настройка межсетевого экрана, в которой приведена минимально безопасная конфигурация iptables, а также страницу Безопасность, где рассмотрена защита системы в целом.

Синхронизация по локальной сети в Dropbox производится с помощью отправки широковещательных пакетов каждые 30 секунд всем доступным компьютерам сети. Если вы находитесь в локальной сети с клиентами Dropbox и не желаете использовать эту возможность, то следует отклонять такие пакеты:

# iptables -A INPUT -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable

# iptables -nvL --line-numbers

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Примечание: Здесь используется действие REJECT, а не DROP, так как в RFC 1122 указано требование к хостам возвращать ICMP-ошибки всегда, когда это возможно, вместо простого отбрасывания пакета. На этой странице поясняется, почему REJECT почти всегда лучше DROP.

Теперь предположим, что вы поменяли своё мнение касательно Dropbox и решили установить его на компьютере. Также вы режили использовать синхронизацию, но с одним конкретным IP-адресом (например, 10.0.0.85). Команда -R позволяет заменить существующее правило:

# iptables -R INPUT 1 -p tcp --dport 17500 ! -s 10.0.0.85 -j REJECT --reject-with icmp-port-unreachable

# iptables -nvL --line-numbers

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     tcp  --  *      *      !10.0.0.85            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Новое правило позволяет хосту 10.0.0.85 отправить данные на порт 17500 вашего компьютера. Но вдруг вы понимаете, что этот подход не масштабируется. Если дружественный пользователь Dropbox пытается получить доступ к порту 17500, то мы хотим предоставлять ему доступ немедленно, не проверяя его последующими правилами!

Поэтому мы пишем новое правило для предоставления доверенному пользователю немедленного доступа и добавляем его командой -I, чтобы вставить его перед предыдущим:

# iptables -I INPUT -p tcp --dport 17500 -s 10.0.0.85 -j ACCEPT -m comment --comment "Friendly Dropbox"

# iptables -nvL --line-numbers

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     tcp  --  *      *       10.0.0.85            0.0.0.0/0            tcp dpt:17500 /* Friendly Dropbox */
2        0     0 REJECT     tcp  --  *      *      !10.0.0.85            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Второе правило теперь можно переписать так, чтобы оно отбрасывало все пакеты на порт 17500 с других хостов:

# iptables -R INPUT 2 -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable

Итоговый список правил теперь выглядит следующим образом:

# iptables -nvL --line-numbers

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     tcp  --  *      *       10.0.0.85            0.0.0.0/0            tcp dpt:17500 /* Friendly Dropbox */
2        0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Руководства

Настройка межсетевого экрана
Router

Журналирование

Цель LOG позволяет при срабатывании правила добавлять информацию о пакете в журнал. В отличие от прочих целей, вроде ACCEPT или DROP, при срабатывании цели LOG пакет продолжает продвижение по цепочке. Поэтому, например, чтобы включить журналирование всех отброшенных пакетов, необходимо перед каждым DROP-правилом добавить аналогичное LOG-правило. Правда, это не очень выгодно с точки зрения эффективности и удобства, и вместо этого лучше создать отдельную цепочку logdrop:

# iptables -N logdrop

Добавьте в неё следующие правила:

# iptables -A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG
# iptables -A logdrop -j DROP

Опции limit и limit-burst объяснены следующем разделе.

Теперь для отбрасывания пакета с добавлением соответствующей записи в журнал необходимо просто выполнить переход на цепочку logdrop:

# iptables -A INPUT -m conntrack --ctstate INVALID -j logdrop

Ограничение скорости логирования

Цепочка logdrop из предыдущего раздела использует модуль limit, который помогает предотвратить разрастание журнала и избежать ненужных операций записи на диск. Если этого не сделать, то неправильно настроенная служба, которая пытается установить соединение, или просто злоумышленник, могут привести к исчерпанию свободного места на диске (как минимум в разделе /var) из-за добавления чрезмерного количества записей в журнал.

Модуль limit подключается опцией -m limit. Опцией --limit задаётся средняя скорость журналирования, а опцией --limit-burst — начальная. В примере цепочки logdrop выше команда

# iptables -A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG

добавляет правило, которое логирует все проходящие через него пакеты. Первые 10 пакетов будут добавлены в журнал, но затем скорость логирования не будет превышать 5 пакетов в минуту. Если значение limit какое-то время не нарушается, то limit-burst снова «разблокируется», т.е. журналирование автоматически вернётся к нормальному режиму.

Просмотр логированных пакетов

В журнале systemd логированные пакеты отображаются как сообщения ядра.

Следующая команда выведет список пакетов, добавленных журнал с момента последней загрузки системы:

# journalctl -k --grep="IN=.*OUT=.*"

syslog-ng

Если вы используете syslog-ng, то в файле syslog-ng.conf можно настроить место хранения логов iptables. Замените:

filter f_everything { level(debug..emerg) and not facility(auth, authpriv); };

на

filter f_everything { level(debug..emerg) and not facility(auth, authpriv) and not filter(f_iptables); };

После этого вывод iptables больше не будет отправляться в /var/log/everything.log.

Если необходимо задать произвольный файл для хранения журнала iptables (вместо /var/log/iptables.log), то измените значение пути в параметре d_iptables (в том же файле (syslog-ng.conf):

destination d_iptables { file("/var/log/iptables.log"); };

ulogd

ulogd — работающий в пространстве пользователя специализированный демон журналирования пакетов для netfilter, который может заменить стандартную цель LOG.

Смотрите также

Iptables в Википедии
Port knocking
Официальный сайт iptables
Руководство по iptables версии 1.2.2 от Oskar Andreasson
Debian Wiki — iptables
Безопасное использование Connection Tracking helpers

Источник

Руководство по Iptables
Глава 1. Введение
1.1. Почему было написано данное руководство
1.2. Как он был написан
1.3. Термины, используемые в данном документе
Глава 2. Подготовка
2.1. Где взять iptables
2.2. Настройка ядра
2.3. Установка пакета
Глава 3. Порядок прохождения таблиц и цепочек.
3.1. Общие положения
3.2. Таблица Mangle
3.3. Таблица Nat
3.4. Таблица Filter
Глава 4. Механизм определения состояний
4.1. Введение
4.2. Таблица трассировщика
4.3. Состояния в пространстве пользователя
4.4. TCP соединения
4.5. UDP соединения
4.6. ICMP соединения
4.7. Поведение по-умолчанию
4.8. Трассировка комплексных протоколов
Глава 5. Сохранение и восстановление больших наборов правил
5.1. Плюсы
5.2. И минусы
5.3. iptables-save
5.4. iptables-restore
Глава 6. Как строить правила
6.1. Основы
6.2. Таблицы
6.3. Команды
6.4. Критерии
6.5. Действия и переходы
Глава 7. Файл rc.firewall
7.1. Пример rc.firewall
7.2. Описание сценария rc.firewall
Глава 8. Примеры сценариев
8.1. Структура файла rc.firewall.txt
8.1.1. Структура
8.2. rc.firewall.txt
8.3. rc.DMZ.firewall.txt
8.4. rc.DHCP.firewall.txt
8.5. rc.UTIN.firewall.txt
8.6. rc.test-iptables.txt
8.7. rc.flush-iptables.txt
8.8. Limit-match.txt
8.9. Pid-owner.txt
8.10. Sid-owner.txt
8.11. Ttl-inc.txt
8.12. Iptables-save ruleset
Приложение A. Детальное описание специальных команд
A.1. Вывод списка правил
A.2. Изменение и очистка ваших таблиц
Приложение B. Общие проблемы и вопросы
B.1. Проблемы загрузки модулей
B.2. Пакеты со статусом NEW и со сброшенным битом SYN
B.3. SYN/ACK — пакеты и пакеты со статусом NEW
B.4. Поставщики услуг Internet, использующие зарезервированные IP-адреса
B.5. Как разрешить прохождение DHCP запросов через iptables
B.6. Проблемы mIRC DCC
Приложение C. Типы ICMP
Приложение D. Ссылки на другие ресурсы
Приложение E. Благодарности

Глава 1. Введение¶

1.1. Почему было написано данное руководство¶

Скажем так, я посчитал, что существует досадный пробел в HOWTO по части информации об iptables и функциях сетевого фильтра (netfilter), реализованных в новой серии ядер 2.4.x Linux. Кроме всего прочего, я попытался ответить на некоторые вопросы по поводу новых возможностей, например проверки состояния пакетов (state matching). Большинство из них проиллюстрированы в файле скрипта rc.firewall.txt, который вы можете вставить в /etc/rc.d/. Для тех, кому интересно, готов сообщить, что этот файл первоначально был основан на masquerading HOWTO.

Там же вы найдете небольшой сценарий rc.flush-iptables.txt, написанный мною, который вы можете использовать, для своих нужд, при необходимости расширяя под свою конфигурацию.

1.2. Как он был написан¶

Я консультировался с Марком Бучером (Marc Boucher) и другими членами команды разработчиков netfilter. Пользуясь случаем, выражаю огромную признательность за их помощь в создании данного руководства, которое изначально было написано для boingworld.com, а теперь доступно на моем персональном сайте frozentux.net. С помощью этого документа вы пройдете процесс настройки шаг за шагом и, надеюсь, что к концу изучения его вы будете знать о пакете iptables значительно больше. Большая часть материала базируется на файле rc.firewall.txt, так как я считаю, что рассмотрение примера — лучший способ изучения iptables. Я пройду по основным цепочкам правил в порядке их следования. Это несколько усложняет изучение, зато изложение становится логичнее. И, всякий раз, когда у вас возникнут затруднения, вы можете обращаться к этому руководству.

1.3. Термины, используемые в данном документе¶

Этот документ содержит несколько терминов, которые следует пояснить прежде, чем вы столкнетесь с ними.

DNAT — от англ. Destination Network Address Translation — Изменение Сетевого Адреса Получателя. DNAT — это изменение адреса назначения в заголовке пакета. Зачастую используется в паре с SNAT. Основное применение — использование единственного реального IP-адреса несколькими компьютерами для выхода в Интернет и предоставления дополнительных сетевых услуг внешним клиентам.

«Поток» (Stream) — под этим термином подразумевается соединение, через которое передаются и принимаются пакеты. Я использовал этот термин для обозначения соединений, через которые передается по меньшей мере 2 пакета в обеих направлениях. В случае TCP это может означать соединение, через которое передается SYN пакет и затем принимается SYN/ACK пакет. Но это так же может подразумевать и передачу SYN пакета и прием сообщения ICMP Host unreachable. Другими словами, я использую этот термин в достаточно широком диапазоне применений.

SNAT — от англ. Source Network Address Translation — Изменение Сетевого Адреса Отправителя. SNAT — это изменение исходного адреса в заголовке пакета. Основное применение — использование единственного реального IP-адреса несколькими компьютерами для выхода в Интернет. В натоящее время диапазон реальных IP-адресов, по стандарту IPv4, недостаточно широк, и его не хватает на всех (переход на IPv6 разрешит эту проблему).

«Состояние» (State) — под этим термином подразумевается состояние, в котором находится пакет, согласно RFC 793 , а также трактовкам, используемым в netfilter/iptables. Хочу обратить ваше внимание на тот факт, что определения состояний пакетов, как для внутренних так и для внешних состояний, используемые Netfilter, не полностью соответствуют указанному выше RFC 793.

«Пространство пользователя» (User space) — под этим термином я подразумеваю все, что расположено за пределами ядра, например: команда iptables -h выполняется за пределами ядра, в то время как команда iptables -A FORWARD -p tcp -j ACCEPT выполняется (частично) в пространстве ядра, поскольку она добавляет новое правило к имеющемуся набору.

«Пространство ядра» (Kernel space) — в большей или меньшей степени является утверждением, обратным термину «Пространство пользователя». Подразумевает место исполнения — в пределах ядра.

«Userland» — см. Пространство пользователя.

Глава 2. Подготовка¶

Целью данной главы является оказание помощи в понимании той роли, которую netfilter и iptables играют в Linux сегодня. Так же она должна помочь вам установить и настроить межсетевой экран (firewall).

2.1. Где взять iptables¶

Пакеты iptables могут быть загружены с домашней страницы проекта Netfilter. Кроме того, для работы iptables соответствующим образом должно быть сконфигурировано ядро вашей Linux-системы. Настройка ядра будет обсуждаться ниже.

2.2. Настройка ядра¶

Для обеспечения базовых возможностей iptables, с помощью утилиты make config или ей подобных (make menuconfig или make xconfig прим. перев.), в ядро должны быть включены следующие опции:
CONFIG_PACKET — Эта опция необходима для приложений, работающих непосредственно с сетевыми устройствами, например: tcpdump или snort.

Строго говоря, опция CONFIG_PACKET не требуется для работы iptables, но, поскольку она используется довольно часто, я включил ее в список. Если вам эта опция не нужна, то можете ее не включать.

CONFIG_NETFILTER — Эта опция необходима, если вы собираетесь использовать компьютер в качестве сетевого экрана (firewall) или шлюза (gateway) в Интернет. Другими словами, вам она определенно понадобится, иначе зачем тогда читать это руководство!
И конечно, нужно добавить драйверы для ваших устройств, т.е. для карты Ethernet, PPP и SLIP. Эти опции необходимы для обеспечения базовых возможностей iptables, для получения дополнительных возможностей придется включить в ядро некоторые дополнительные опции. Ниже приводится список опций для ядра 2.4.9 и их краткое описание:

CONFIG_IP_NF_CONNTRACK — Трассировка соединений. Трассировка соединений, среди всего прочего, используется при трансляции сетевых адресов и маскарадинге (NAT и Masquerading). Если вы собираетесь строить сетевой экран (firewall) для локальной сети, то вам определенно потребуется эта опция. К примеру, этот модуль необходим для работы rc.firewall.txt.

CONFIG_IP_NF_FTP — Трассировка FTP соединений. Обмен по FTP идет слишком интенсивно, чтобы использовать обычные методы трассировки. Если не добавить этот модуль, то вы столкнетесь с трудностями при передаче протокола FTP через сетевой экран (firewall).

CONFIG_IP_NF_IPTABLES — Эта опция необходима для выполнения операций фильтрации, преобразования сетевых адресов (NAT) и маскарадинга (masquerading). Без нее вы вообще ничего не сможете делать с iptables.

CONFIG_IP_NF_MATCH_LIMIT — Этот модуль необязателен, однако он используется в примерах rc.firewall.txt. Он предоставляет возможность ограничения количества проверок для некоторого правила. Например, -m limit —limit 3/minute указывает, что заданное правило может пропустить не более 3-х пакетов в минуту. Таким образом, данный модуль может использоваться для защиты от нападений типа «Отказ в обслуживании».

CONFIG_IP_NF_MATCH_MAC — Этот модуль позволит строить правила, основанные на MAC-адресации. Как известно, каждая сетевая карта имеет свой собственный уникальный Ethernet-адрес, таким образом, существует возможность блокировать пакеты, поступающие с определенных MAC-адресов (т.е. с определенных сетевых карт). Следует, однако, отметить что данный модуль не используется в rc.firewall.txt или где либо еще в данном руководстве.

CONFIG_IP_NF_MATCH_MARK — Функция маркировки пакетов MARK. Например, при использовании функции MARK мы получаем возможность пометить требуемые пакеты, а затем, в других таблицах, в зависимости от значения метки, принимать решение о маршрутизации помеченного пакета. Более подробное описание функции MARK приводится ниже в данном документе.

CONFIG_IP_NF_MATCH_MULTIPORT — Этот модуль позволит строить правила с проверкой на принадлежность пакета к диапазону номеров портов источника/приемника.

CONFIG_IP_NF_MATCH_TOS — Этот модуль позволит строить правила, отталкиваясь от состояния поля TOS в пакете. Поле TOS устанавливается для Type Of Service. Так же становится возможным устанавливать и сбрасывать биты этого поля в собственных правилах в таблице mangle или командами ip/tc.

CONFIG_IP_NF_MATCH_TCPMSS — Эта опция добавляет возможность проверки поля MSS в TCP-пакетах.

CONFIG_IP_NF_MATCH_STATE — Это одно из самых серьезных усовершенствований по сравнению с ipchains. Этот модуль предоставляет возможность управления TCP пакетами, основываясь на их состоянии (state). К примеру, допустим, что мы имеем установленное TCP соединение, с траффиком в оба конца, тогда пакет полученный по такому соединению будет считаться ESTABLISHED (установленное соединение — прим. ред). Эта возможность широко используется в примере rc.firewall.txt.

CONFIG_IP_NF_MATCH_UNCLEAN — Этот модуль реализует возможность дополнительной проверки IP, TCP, UDP и ICMP пакетов на предмет наличия в них несоответствий, «странностей», ошибок. Установив его мы, к примеру, получим возможность «отсекать» подобного рода пакеты. Однако хочется отметить, что данный модуль пока находится на экспериментальной стадии и не во всех случаях будет работать одинаково, поэтому никогда нельзя будет быть уверенным, что мы не «сбросили» вполне правильные пакеты.

CONFIG_IP_NF_MATCH_OWNER — Проверка «владельца» соединения (socket). Для примера, мы можем позволить только пользователю root выходить в Internet. Этот модуль был написан как пример работы с iptables. Следует заметить, что данный модуль имеет статус экспериментального и может не всегда выполнять свои функции.

CONFIG_IP_NF_FILTER — Реализация таблицы filter в которой в основном и осуществляется фильтрация. В данной таблице находятся цепочки INPUT, FORWARD и OUTPUT. Этот модуль обязателен, если вы планируете осуществлять фильтрацию пакетов.

CONFIG_IP_NF_TARGET_REJECT — Добавляется действие REJECT, которое производит передачу ICMP-сообщения об ошибке в ответ на входящий пакет, который отвергается заданным правилом. Запомните, что TCP соединения, в отличие от UDP и ICMP, всегда завершаются или отвергаются пакетом TCP RST.

CONFIG_IP_NF_TARGET_MIRROR — Возможность отправки полученного пакета обратно (отражение). Например, если назначить действие MIRROR для пакетов, идущих в порт HTTP через нашу цепочку INPUT (т.е. на наш WEB-сервер прим. перев.), то пакет будет отправлен обратно (отражен) и, в результате, отправитель увидит свою собственную домашнюю страничку. (Тут одни сплошные «если»: Если у отправителя стоит WEB-сервер, если он работает на том же порту, если у отправителя есть домашняя страничка, и т.д. . Суть-то собственно сводится к тому, что с точки зрения отправителя все выглядит так, как будто бы пакет он отправил на свою собственную машину, а проще говоря, действие MIRROR меняет местами адрес отправителя и получателя и выдает измененный пекет в сеть прим. перев.)

CONFIG_IP_NF_NAT — Трансляция сетевых адресов в различных ее видах. С помощью этой опции вы сможете дать выход в Интернет всем компьютерам вашей локальной сети, имея лишь один уникальный IP-адрес. Эта опция необходима для работы примера rc.firewall.txt.

CONFIG_IP_NF_TARGET_MASQUERADE — Маскарадинг. В отличие от NAT, маскарадинг используется в тех случаях, когда заранее неизвестен наш IP-адрес в Интернете, т.е. для случаев DHCP, PPP, SLIP или какого-либо другого способа подключения, подразумевающего динамическое получение IP-адреса. Маскарадинг дает несколько более высокую нагрузку на компьютер, по сравнению с NAT, однако он работает в ситуациях, когда невозможно заранее указать собственный внешний IP-адрес.

CONFIG_IP_NF_TARGET_REDIRECT — Перенаправление. Обычно это действие используется совместно с проксированием. Вместо того, чтобы просто пропустить пакет дальше, это действие перенаправляет пакет на другой порт сетевого экрана (прокси-серверу прим. перев.). Другими словами, таким способом мы можем выполнять «прозрачное проксирование».

CONFIG_IP_NF_TARGET_LOG — Добавляет действие LOG в iptables. Мы можем использовать этот модуль для фиксации отдельных пакетов в системном журнале (syslog). Эта возможность может оказаться весьма полезной при отладке ваших сценариев.

CONFIG_IP_NF_TARGET_TCPMSS — Эта опция может использоваться для преодоления ограничений, накладываемых некоторыми провайдерами (Internet Service Providers), которые блокируют ICMP Fragmentation Needed пакеты. В результате таких ограничений серверы провайдеров могут не передавать web-страницы, ssh может работать, в то время как scp обрывается после установления соединения и пр. Для преодоления подобного рода ограничений мы можем использовать действие TCPMSS ограничивая значение MSS (Maximum Segment Size) (обычно MSS ограничивается размером MTU исходящего интерфейса минус 40 байт прим. перев.). Таким образом мы получаем возможность преодолеть то, что авторы netfilter называют «преступной безмозглостью провайдеров или серверов» («criminally braindead ISPs or servers») в справке по конфигурации ядра.

CONFIG_IP_NF_COMPAT_IPCHAINS — Добавляет совместимость с более старой технологией ipchains. Вполне возможно, что подобного рода совместимость будет сохранена и в ядрах серии 2.6.x.

CONFIG_IP_NF_COMPAT_IPFWADM — Добавляет совместимость с ipfwadm, не смотря на то что это очень старое средство построения брандмауэров.

Как вы можете видеть, я дал краткую характеристику каждому модулю. Данные опции доступны в ядре версии 2.4.9. Если вам потребуются дополнительные возможности — советую обратить внимание на расширения patch-o-matic, которые добавляют достаточно большое количество дополнительных функций к Netfilter. Patch-o-matic — это набор дополнений, которые, как предполагается, в будущем будут включены в состав ядра.

Для работы сценария rc.firewall.txt вам необходимо будет добавить в ядро следующие опции или собрать соответствующие подгружаемые модули. За информацией по опциям, необходимым для работы других сценариев, обращайтесь к приложению с примерами этих сценариев.

CONFIG_PACKET
CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_FTP
CONFIG_IP_NF_IRC
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_TARGET_LOG
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_TARGET_MASQUERADE

Выше приведен список минимально необходимых опций ядра для сценария rc.firewall.txt Перечень опций, необходимых для других примеров сценариев вы сможете найти в соответствующих разделах ниже. Сейчас же мы остановимся на главном сценарии и начнем его изучение.

2.3. Установка пакета¶

В первую очередь посмотрим как собрать (скомпилировать) пакет iptables. Сборка пакета в значительной степени зависит от конфигурации ядра и вы должны это понимать. Некоторые дистрибутивы предполагают предустановку пакета iptables, один из них — Red Hat. Однако, в RedHat этот пакет по умолчанию выключен, поэтому ниже мы рассмотрим как его включить в данном и в других дистрибутивах.

2.3.1. Сборка пакета

Для начала пакет с исходными текстами iptables нужно распаковать. Мы будем рассматривать пакет iptables 1.2.6a и ядро серии 2.4. Распакуем как обычно, командой bzip2 -cd iptables-1.2.6a.tar.bz2 | tar -xvf — (распаковку можно выполнить также командой tar -xjvf iptables-1.2.6a.tar.bz2). Если распаковка прошла удачно, то пакет будет размещен в каталоге iptables-1.2.6a. За дополнительной информацией вы можете обратиться к файлу iptables-1.2.6a/INSTALL, который содержит подробную информацию по сборке и установке пакета.

Далее необходимо проверить включение в ядро дополнительных модулей и опций. Шаги, описываемые здесь, будут касаться только наложения «заплат» (patches) на ядро. На этом шаге мы установим обновления, которые, как ожидается, будут включены в ядро в будущем.

Некоторые из них находятся пока на экспериментальной стадии и наложение этих заплат может оказаться не всегда оправданной, однако среди них есть чрезвычайно интересные функции и действия.

Выполним этот шаг, набрав команду (естественно, обладая правами пользователя root):

make pending-patches KERNEL_DIR=/usr/src/linux/

Переменная KERNEL_DIR должна содержать путь к исходным текстам вашего ядра. Обычно это /usr/src/linux/. Если исходные тексты у вас расположены в другом месте, то, соответственно, вы должны указать свой путь.

Здесь предполагается выполнить несколько обновлений и дополнений, которые определенно войдут в состав ядра, но несколько позднее, сейчас же мы возьмем их отсюда выполнив команду:
make most-of-pom KERNEL_DIR=/usr/src/linux/

В процессе выполнения вышеприведенной команды у вас будет запрашиваться подтверждение на обновление каждого раздела из того, что в мире netfilter называется patch-o-matic. Чтобы установить все «заплатки» из patch-o-matic, вам нужно выполнить следующую команду:

make patch-o-matic KERNEL_DIR=/usr/src/linux/

Не забудьте внимательно и до конца прочитать справку по каждой «заплатке» до того как вы будете устанавливать что-либо, поскольку одни «заплатки» могут оказаться несовместимы с другими, а некоторые — при совместном наложении даже разрушить ядро.

Вы можете вообще пропустить обновление ядра, другими словами особой нужды в таком обновлении нет, однако patch-o-matic содержит действительно интересные обновления, и у вас вполне может возникнуть желание посмотреть на них. Ничего страшного не случится, если вы запустите эти команды и посмотрите какие обновления имеются.

После завершения обновления, вам необходимо будет пересобрать ядро, добавив в него только что установленные обновления. Не забудьте сначала выполнить конфигурирование ядра, поскольку установленные обновления скорее всего окажутся выключенными. В принципе, можно подождать с компиляцией ядра до тех пор пока вы не закончите установку iptables.

Продолжая сборку iptables, запустите команду:

make KERNEL_DIR=/usr/src/linux/

Если в процессе сборки возникли какие либо проблемы, то можете попытаться разрешить их самостоятельно, либо обратиться на Netfilter mailing list, где вам смогут помочь. Там вы найдете пояснения, что могло быть сделано вами неправильно при установке, так что сразу не паникуйте. Если это не помогло — постарайтесь поразмыслить логически, возможно это поможет. Или обратитесь к знакомому «гуру».

Если все прошло гладко, то следовательно вы готовы к установке исполняемых модулей (binaries), для чего запустите следующую команду:

make install KERNEL_DIR=/usr/src/linux/

Надеюсь, что здесь-то проблем не возникло! Теперь для использования пакета iptables вам определенно потребуется пересобрать и переустановить ядро, если вы до сих пор этого не сделали. Дополнительную информацию по установке пакета вы найдете в файле INSTALL.

2.3.2. Установка в Red Hat 7.1

RedHAt 7.1, с установленным ядром 2.4.x уже включает предустановленные netfilter и iptables. Однако, для сохранения обратной совместимости с предыдущими дистрибутивами, по умолчанию работает пакет ipchains. Сейчас мы коротко разберем — как удалить ipchains и запустить вместо него iptables.

Версия iptables в Red Hat 7.1 сильно устарела и, наверное неплохим решением будет установить более новую версию.

Для начала нужно отключить ipchains, чтобы предотвратить загрузку соответствующих модулей в будущем. Чтобы добиться этого, нам потребуется изменить имена некоторых файлов в дереве каталогов /etc/rc.d/. Следующая команда, выполнит требуемые действия:

chkconfig —level 0123456 ipchains off

В результате выполнения этой команды, в некоторых именах ссылок, указывающих на файлы в каталоге /etc/rc.d/init.d/ipchains, символ S (который сообщает, что данный сценарий отрабатывает на запуске системы) будет заменен символом K (от слова Kill, который указывает на то, что сценарий отрабатывает, при завершении работы системы. Таким образом мы предотвратим запуск ненужного сервиса в будущем.

Однако ipchains по-прежнему остаются в работе. Теперь надо выполнить команду, которая остановит этот сервис:

service ipchains stop

И в заключение необходимо запустить сервис iptables. Для этого, во-первых, надо определиться с уровнями запуска операционной системы, на которых нужно стартовать этот сервис. Обычно это уровни 2, 3 и 5. Об этих уровнях мы знаем:

2. Многопользовательский режим без поддержки NFS или то же самое, что и 3, но без сетевой поддержки.
3. Полнофункциональный многопользовательский режим.
5. X11. Данный уровень используется для автоматической загрузки Xwindows.

Чтобы запустить iptables на этих уровнях нужно выполнить команду:

chkconfig —level 235 iptables on

Хочется упомянуть об уровнях, на которых не требуется запуска iptables: Уровень 1 — однопользовательский режим работы, как правило используется в экстренных случаях, когда мы «поднимаем» «упавшую» систему. Уровень 4 — вообще не должен использоваться. Уровень выполнения 6 — это уровень остановки системы при выключении или перезагрузке компьютера.

Для активации сервиса iptables подадим команду:

service iptables start

Итак, мы запустили iptables, но у нас пока еще нет ни одного правила. Чтобы добавить новые правила в Red Hat 7.1 можно пойти двумя путями, во-первых: подправить файл /etc/rc.d/init.d/iptables, но этот способ имеет одно негативное свойство — при обновлении iptables из RPM-пакетов все ваши правила будут утеряны, а во-вторых: занести правила и сохранить их командой iptables-save, сохраненные таким образом правила будут автоматически восстанавливаться при загрузке системы.

В случае, если вы избрали первый вариант установки правил в iptables, то вам необходимо занести их в секцию start сценария /etc/rc.d/init.d/iptables (для установки правил при загрузке системы) или в функцию start(). Для выполнения действий при остановке системы — внесите соответствующие изменения в секцию stop) или в функцию stop(). Так же не забудьте про секции restart и condrestart. Хочется еще раз напомнить, что в случае обновления iptables из RPM-пакетов или через автоматическое обновление по сети, вы можете утерять все изменения, внесенные в файл /etc/rc.d/init.d/iptables.

Второй способ загрузки правил предпочтительнее. Он предполагает следующие шаги. Для начала — запишите правила в файл или непосредственно, через команду iptables, смотря что для вас предпочтительнее. Затем исполните команду iptables-save. Эта команда эквивалентна команде iptables-save > /etc/sysconfig/iptables. В результате, весь набор правил будет сохранен в файле /etc/sysconfig/iptables, который автоматически подгружается при запуске сервиса iptables. Другим способом сохранить набор правил будет подача команды service iptables save, которая полностью идентична вышеприведенной команде. Впоследствии, при перезагрузке компьютера, сценарий iptables из rc.d будет выполнять команду iptables-restore для загрузки набора правил из файла /etc/sysconfig/iptables.

И наконец, в завершение установки, неплохо было бы удалить старые версии ipchains и iptables. Это необходимо сделать для того, чтобы система не «перепутала» старый пакет iptables с вновь установленным. Удаление старого пакета iptables необходимо произвести только в том случае, если вы производили установку из исходных текстов. Дело в том, что RPM пакеты устанавливаются в несколько иное место нежели пакеты, собранные из исходных текстов, а поэтому новый пакет не «затирает» старый. Чтобы выполнить деинсталляцию предыдущей версии iptables выполните следующую команду:

rpm -e iptables

Аналогичным образом удалим и ipchains, поскольку оставлять этот пакет в системе более нет никакого смысла.

rpm -e ipchains

Глава 3. Порядок прохождения таблиц и цепочек.¶

В этой главе мы рассмотрим порядок прохождения таблиц и цепочек в каждой таблице. Эта информация будет очень важна для вас позднее, когда вы начнете строить свои наборы правил, особенно когда в наборы правил будут включаться такие действия как DNAT, SNAT и конечно же TOS.

3.1. Общие положения¶

Когда пакет приходит на наш брандмауэр, то он сперва попадает на сетевое устройство, перехватывается соответствующим драйвером и далее передается в ядро. Далее пакет проходит ряд таблиц и затем передается либо локальному приложению, либо переправляется на другую машину. Порядок следования пакета приводится ниже:

Таблица 3-1. Порядок движения транзитных пакетов

Шаг	Таблица	Цепочка	Примечание
1			Кабель (т.е. Интернет)
2			Сетевой интерфейс (например, eth0)
3	mangle	PREROUTING	Обычно эта цепочка используется для внесения изменений в заголовок пакета, например для изменения битов TOS и пр..
4	nat	PREROUTING	Эта цепочка используется для трансляции сетевых адресов (`Destination Network Address Translation`). Source Network Address Translation выполняется позднее, в другой цепочке. Любого рода фильтрация в этой цепочке может производиться только в исключительных случаях
5			Принятие решения о дальнейшей маршрутизации, т.е. в этой точке решается куда пойдет пакет — локальному приложению или на другой узел сети.
6	mangle	FORWARD	Далее пакет попадает в цепочку `FORWARD` таблицы mangle, которая должна использоваться только в исключительных случаях, когда необходимо внести некоторые изменения в заголовок пакета между двумя точками принятия решения о маршрутизации.
7	Filter	FORWARD	В цепочку FORWARD попадают только те пакеты, которые идут на другой хост Вся фильтрация транзитного трафика должна выполняться здесь. Не забывайте, что через эту цепочку проходит траффик в обоих направлениях, обязательно учитывайте это обстоятельство при написании правил фильтрации.
8	mangle	POSTROUTING	Эта цепочка предназначена для внесения изменений в заголовок пакета уже после того как принято последнее решение о маршрутизации.
9	nat	POSTROUTING	Эта цепочка предназначена в первую очередь для Source Network Address Translation. Не используйте ее для фильтрации без особой на то необходимости. Здесь же выполняется и маскарадинг (Masquerading).
10			Выходной сетевой интерфейс (например, eth1).
11			Кабель (пусть будет LAN).

Как вы можете видеть, пакет проходит несколько этапов, прежде чем он будет передан далее. На каждом из них пакет может быть остановлен, будь то цепочка iptables или что либо еще, но нас главным образом интересует iptables. Заметьте, что нет каких либо цепочек, специфичных для отдельных интерфейсов или чего либо подобного. Цепочку FORWARD проходят ВСЕ пакеты, которые движутся через наш брандмауэр/ роутер. Не используйте цепочку INPUT для фильтрации транзитных пакетов, они туда просто не попадают! Через эту цепочку движутся только те пакеты, которые предназначены данному хосту!

А теперь рассмотрим порядок движения пакета, предназначенного локальному процессу/приложению:

Таблица 3-2. Для локального приложения

Шаг	Таблица	Цепочка	Примечание
1			Кабель (т.е. Интернет)
2			Входной сетевой интерфейс (например, eth0)
3	mangle	PREROUTING	Обычно используется для внесения изменений в заголовок пакета, например для установки битов TOS и пр.
4	nat	PREROUTING	Преобразование адресов (`Destination Network Address Translation`). Фильтрация пакетов здесь допускается только в исключительных случаях.
5			Принятие решения о маршрутизации.
6	mangle	INPUT	Пакет попадает в цепочку INPUT таблицы mangle. Здесь внесятся изменения в заголовок пакета перед тем как он будет передан локальному приложению.
7	filter	INPUT	Здесь производится фильтрация входящего трафика. Помните, что все входящие пакеты, адресованные нам, проходят через эту цепочку, независимо от того с какого интерфейса они поступили.
8			Локальный процесс/приложение (т.е., программа-сервер или программа-клиент)

Важно помнить, что на этот раз пакеты идут через цепочку INPUT, а не через FORWARD.

И в заключение мы рассмотрим порядок движения пакетов, созданных локальными процессами.

Таблица 3-3. От локальных процессов

Шаг	Таблица	Цепочка	Примечание
1			Локальный процесс (т.е., программа-сервер или программа-клиент).
2			Принятие решения о маршрутизации. Здесь решается куда пойдет пакет дальше — на какой адрес, через какой сетевой интерфейс и пр.
3	mangle	OUTPUT	Здесь производится внесение изменений в заголовок пакета. Выполнение фильтрации в этой цепочке может иметь негативные последствия.
4	nat	OUTPUT	Эта цепочка используется для трансляции сетевых адресов (NAT) в пакетах, исходящих от локальных процессов брандмауэра.
5	Filter	OUTPUT	Здесь фильтруется исходящий траффик.
6	mangle	POSTROUTING	Цепочка `POSTROUTING` таблицы mangle в основном используется для правил, которые должны вносить изменения в заголовок пакета перед тем, как он покинет брандмауэр, но уже после принятия решения о маршрутизации. В эту цепочку попадают все пакеты, как транзитные, так и созданные локальными процессами брандмауэра.
7	nat	POSTROUTING	Здесь выполняется `Source Network Address Translation`. Не следует в этой цепочке производить фильтрацию пакетов во избежание нежелательных побочных эффектов. Однако и здесь можно останавливать пакеты, применяя политику по-умолчанию DROP.
8			Сетевой интерфейс (например, eth0)
9			Кабель (т.е., Internet)

Теперь мы знаем, что есть три различных варианта прохождения пакетов. Рисунок ниже более наглядно демонстрирует это:

Этот рисунок дает довольно ясное представление о порядке прохождения пакетов через различные цепочки. В первой точке принятия решения о маршрутизации (routing decision) все пакеты, предназначенные данному хосту направляются в цепочку INPUT, остальные — в цепочку FORWARD.

Обратите внимание также на тот факт, что пакеты, с адресом назначения на брандмауэр, могут претерпеть изменение сетевого адреса назначения (DNAT) в цепочке PREROUTING таблицы nat и соответственно дальнейшая маршрутизация в первой точке будет выполняться в зависимости от произведенных изменений. Запомните — все пакеты проходят через таблицы и цепочки по тому или иному маршруту. Даже если выполняется DNAT в ту же сеть, откуда пакет пришел, то он все равно продолжит движение по цепочкам.

В сценарии rc.test-iptables.txt вы сможете найти дополнительную информацию о порядке прохождения пакетов.

3.2. Таблица Mangle¶

Как уже упоминалось выше, эта таблица предназначена, главным образом для внесения изменений в заголовки пакетов (mangle — искажать, изменять. прим. перев.). Т.е. в этой таблице вы можете устанавливать биты TOS (Type Of Service) и т.д.

Еще раз напоминаю вам, что в этой таблице не следует производить любого рода фильтрацию, маскировку или преобразование адресов (DNAT, SNAT, MASQUERADE).

В этой таблице допускается выполнять только нижеперечисленные действия:

TOS
TTL
MARK

Действие TOS выполняет установку битов поля Type of Service в пакете. Это поле используется для назначения сетевой политики обслуживания пакета, т.е. задает желаемый вариант маршрутизации. Однако, следует заметить, что данное свойство в действительности используется на незначительном количестве маршрутизаторов в Интернете. Другими словами, не следует изменять состояние этого поля для пакетов, уходящих в Интернет, потому что на роутерах, которые таки обслуживают это поле, может быть принято неправильное решение при выборе маршрута.

Действие TTL используется для установки значения поля TTL (Time To Live) пакета. Есть одно неплохое применение этому действию. Мы можем присваивать определенное значение этому полю, чтобы скрыть наш брандмауэр от чересчур любопытных провайдеров (Internet Service Providers). Дело в том, что отдельные провайдеры очень не любят когда одно подключение разделяется несколькими компьютерами. и тогда они начинают проверять значение TTL приходящих пакетов и используют его как один из критериев определения того, один компьютер «сидит» на подключении или несколько.

Действие MARK устанавливает специальную метку на пакет, которая затем может быть проверена другими правилами в iptables или другими программами, например iproute2. С помощью «меток» можно управлять маршрутизацией пакетов, ограничивать траффик и т.п.

3.3. Таблица Nat¶

Эта таблица используется для выполнения преобразований сетевых адресов NAT (Network Address Translation). Как уже упоминалось ранее, только первый пакет из потока проходит через цепочки этой таблицы, трансляция адресов или маскировка применяются ко всем последующим пакетам в потоке автоматически. Для этой таблицы характерны действия:

DNAT
SNAT
MASQUERADE

Действие DNAT (Destination Network Address Translation) производит преобразование адресов назначения в заголовках пакетов. Другими словами, этим действием производится перенаправление пакетов на другие адреса, отличные от указанных в заголовках пакетов.

SNAT (Source Network Address Translation) используется для изменения исходных адресов пакетов. С помощью этого действия можно скрыть структуру локальной сети, а заодно и разделить единственный внешний IP адрес между компьютерами локальной сети для выхода в Интернет. В этом случае брандмауэр, с помощью SNAT, автоматически производит прямое и обратное преобразование адресов, тем самым давая возможность выполнять подключение к серверам в Интернете с компьютеров в локальной сети.

Маскировка (MASQUERADE) применяется в тех же целях, что и SNAT, но в отличие от последней, MASQUERADE дает более сильную нагрузку на систему. Происходит это потому, что каждый раз, когда требуется выполнение этого действия — производится запрос IP адреса для указанного в действии сетевого интерфейса, в то время как для SNAT IP адрес указывается непосредственно. Однако, благодаря такому отличию, MASQUERADE может работать в случаях с динамическим IP адресом, т.е. когда вы подключаетесь к Интернет, скажем через PPP, SLIP или DHCP.

3.4. Таблица Filter¶

Как следует из названия, в этой таблице должны содержаться наборы правил для выполнения фильтрации пакетов. Пакеты могут пропускаться далее, либо отвергаться (действия ACCEPT и DROP соответственно), в зависимости от их содержимого. Конечно же, мы можем отфильтровывать пакеты и в других таблицах, но эта таблица существует именно для нужд фильтрации. В этой таблице допускается использование большинства из существующих действий, однако ряд действий, которые мы рассмотрели выше в этой главе, должны выполняться только в присущих им таблицах.

Глава 4. Механизм определения состояний¶

В данной главе все внимание будет уделено механизму определения состояний пакетов (state machine). По прочтении ее у вас должно сложиться достаточно четкое представление о работе механизма, а способствовать этому должен значительный объем поясняющих примеров.

4.1. Введение¶

Механизм определения состояния (state machine) является отдельной частью iptables и в действительности не должен бы так называться, поскольку фактически является механизмом трассировки соединений. Однако значительному количеству людей он известен именно как «механизм определения состояния» (state machine). В данной главе эти названия будут использоваться как синонимы. Трассировщик соединений создан для того, чтобы netfilter мог постоянно иметь информацию о состоянии каждого конкретного соединения. Наличие трассировщика позволяет создавать более надежные наборы правил по сравнению с брандмауэрами, которые не имеют поддержки такого механизма.

В пределах iptables, соединение может иметь одно из 4-х базовых состояний: NEW, ESTABLISHED, RELATED и INVALID. Позднее мы остановимся на каждом из них более подробно. Для управления прохождением пакетов, основываясь на их состоянии, используется критерий --state.

Трассировка соединений производится специальным кодом в пространстве ядра — трассировщиком (conntrack). Код трассировщика может быть скомпилирован как подгружаемый модуль ядра, так и статически связан с ядром. В большинстве случаев нам потребна более специфичная информация о соединении, чем та, которую поставляет трассировщик по-умолчанию. Поэтому трассировщик включает в себя обработчики различных протоколов, например TCP, UDP или ICMP. Собранная ими информация затем используется для идентификации и определения текущего состояния соединения. Например — соединение по протоколу UDP однозначно идентифицируется по IP-адресам и портам источника и приемника.

В предыдущих версиях ядра имелась возможность включения/выключения поддержки дефрагментации пакетов. Однако, после того как трассировка соединений была включена в состав iptables/netfilter, надобность в этом отпала. Причина в том, что трассировщик не в состоянии выполнять возложенные на него функции без поддержки дефрагментации и поэтому она включена постоянно. Ее нельзя отключить иначе как отключив трассировку соединений. Дефрагментация выполняется всегда, если трассировщик включен.

Трассировка соединений производится в цепочке PREROUTING, исключая случаи, когда пакеты создаются локальными процессами на брандмауэре, в этом случае трассировка производится в цепочке OUTPUT. Это означает, что iptables производит все вычисления, связанные с определением состояния, в пределах этих цепочек. Когда локальный процесс на брандмауэре отправляет первый пакет из потока, то в цепочке OUTPUT ему присваивается состояние NEW, а когда возвращается пакет ответа, то состояние соединения в цепочке PREROUTING изменяется на ESTABLISHED, и так далее. Если же соединение устанавливается извне, то состояние NEW присваивается первому пакету из потока в цепочке PREROUTING. Таким образом, определение состояния пакетов производится в пределах цепочек PREROUTING и OUTPUT таблицы nat.

4.2. Таблица трассировщика¶

Кратко рассмотрим таблицу трассировщика, которую можно найти в файле /proc/net/ip_conntrack. Здесь содержится список всех активных соединений. Если модуль ip_conntrack загружен, то команда cat /proc/net/ip_conntrak должна вывести нечто, подобное:

tcp  6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 
dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22
dport=32775 use=2

В этом примере содержится вся информация, которая известна трассировщику, по конкретному соединению. Первое, что можно увидеть — это название протокола, в данном случае — tcp. Далее следует некоторое число в обычном десятичном представлении. После него следует число, определяющее «время жизни» записи в таблице (т.е. количество секунд, через которое информация о соединении будет удалена из таблицы). Для нашего случая, запись в таблице будет храниться еще 117 секунд, если конечно через это соединение более не проследует ни одного пакета. При прохождении каждого последующего пакета через данное соединение, это значение будет устанавливаться в значение по-умолчанию для заданного состояния. Это число уменьшается на 1 каждую секунду. Далее следует фактическое состояние соединения. Для нашего примера состояние имеет значение SYN_SENT. Внутреннее представление состояния несколько отличается от внешнего. Значение SYN_SENT говорит о том, что через данное соединение проследовал единственный пакет TCP SYN. Далее расположены адреса отправителя и получателя, порт отправителя и получателя. Здесь же видно ключевое слово [UNREPLIED], которое сообщает о том, что ответного трафика через это соединение еще не было. И наконец приводится дополнительная информация по ожидаемому пакету, это IP адреса отправителя/получателя (те же самые, только поменявшиеся местами, поскольку ожидается ответный пакет), то же касается и портов.

Записи в таблице могут принимать ряд значений, все они определены в заголовочных файлах linux/include/netfilter-ipv4/ip_conntrack*.h. Значения по-умолчанию зависят от типа протокола. Каждый из IP-протоколов — TCP, UDP или ICMP имеют собственные значения по-умолчанию, которые определены в заголовочном файле linux/include/netfilter-ipv4/ip_conntrack.h. Более подробно мы остановимся на этих значениях, когда будем рассматривать каждый из протоколов в отдельности.

Совсем недавно, в patch-o-matic, появилась заплата tcp-window-tracking, которая предоставляет возможность передачи значений всех таймаутов через специальные переменные, т.е. позволяет изменять их «на лету». Таким образом появляется возможность изменения таймаутов без необходимости пересборки ядра.
Изменения вносятся с помощью определенных системных вызовов, через каталог /proc/sys/net/ipv4/netfilter. Особое внимание обратите на ряд переменных /proc/sys/net/ipv4/netfilter/ip_ct_*.

После получения пакета ответа трассировщик снимет флаг [UNREPLIED] и заменит его флагом [ASSURED]. Этот флаг сообщает о том, что соединение установлено уверенно и эта запись не будет стерта по достижении максимально возможного количества трассируемых соединений. Максимальное количество записей, которое может содержаться в таблице зависит от значения по-умолчанию, которое может быть установлено вызовом функции ipsysctl в последних версиях ядра. Для объема ОЗУ 128 Мб это значение соответствует 8192 записям, для 256 Мб — 16376. Вы можете посмотреть и изменить это значение установкой переменной /proc/sys/net/ipv4/ip_conntrack_max.

4.3. Состояния в пространстве пользователя¶

Как вы уже наверняка заметили, в пространстве ядра, в зависимости от типа протокола, пакеты могут иметь несколько различных состояний. Однако, вне ядра пакеты могут иметь только 4 состояния. В основном состояние пакета используется критерием --state. Допустимыми являются состояния NEW, ESTABLISHED, RELATED и INVALID. В таблице, приводимой ниже, рассмтриваются каждое из возможных состояний.

Таблица 4-1. Перечень состояний в пространстве пользователя

Состояние	Описание
NEW	Признак NEW сообщает о том, что пакет является первым для данного соединения. Это означает, что это первый пакет в данном соединении, который увидел модуль трассировщика. Например если получен SYN пакет являющийся первым пакетом для данного соединения, то он получит статус `NEW`. Однако, пакет может и не быть `SYN` пакетом и тем не менее получить статус `NEW`. Это может породить определенные проблемы в отдельных случаях, но может оказаться и весьма полезным, например когда желательно «подхватить» соединения, «потерянные» другими брандмауэрами или в случаях, когда таймаут соединения уже истек, но само соединение не было закрыто.
RELATED	Состояние `RELATED` одно из самых «хитрых». Соединение получает статус `RELATED` если оно связано с другим соединением, имеющим признак `ESTABLISHED`. Это означает, что соединение получает признак `RELATED` тогда, когда оно инициировано из уже установленного соединения, имеющего признак `ESTABLISHED`. Хорошим примером соединения, которое может рассматриваться как `RELATED`, является соединение FTP-data, которое является связанным с портом FTP control, а так же DCC соединение, запущенное из `IRC`. Обратите внимание на то, что большинство протоколов `TCP` и некоторые из протоколов `UDP` весьма сложны и передают информацию о соединении через область данных `TCP` или `UDP` пакетов и поэтому требуют наличия специальных вспомогательных модулей для корректной работы.
ESTABLISHED	Состояние `ESTABLISHED` говорит о том, что это не первый пакет в соединении. Схема установки состояния `ESTABLISHED` достаточна проста для понимания. Единственное требование, предъявляемое к соединению, заключается в том, что для перехода в состояние `ESTABLISHED` необходимо чтобы узел сети передал пакет и получил на него ответ от другого узла (хоста). После получения ответа состояние соединения `NEW` или `RELATED` будет изаменено на `ESTABLISHED`.
INVALID	Признак `INVALID` говорит о том, что пакет не может быть идентифицирован и поэтому не может иметь определенного статуса. Это может происходить по разным причинам, например при нехватке памяти или при получении `ICMP`-сообщения об ошибке, которое не соответствует какому либо известному соединению. Наверное наилучшим вариантом было бы применение действия `DROP` к таким пакетам.

Эти четыре состояния могут использоваться в критерии --state. Механизм определения состояния позволяет строить чрезвычайно мощную и эффективную защиту. Раньше приходилось открывать все порты выше 1024, чтобы пропустить обратный трафик в локальную сеть, теперь же, при наличии механизма определения состояния, необходимость в этом отпала, поскольку появилась возможность «открывать» доступ только для обратного (ответного) трафика, пресекая попытки установления соединений извне.

4.4. TCP соединения¶

В этом и в последующих разделах мы поближе рассмотрим признаки состояний и порядок их обработки каждым из трех базовых протоколов TCP, UDP и ICMP, а так же коснемся случая, когда протокол соединения не может быть классифицирован на принадлежность к трем, вышеуказанным, протоколам. Начнем рассмотрение с протокола TCP, поскольку он имеет множество интереснейших особенностей в отношении механизма определения состояния в iptables.

TCP соединение всегда устанавливается передачей трех пакетов, которые инициализируют и устанавливают соединение, через которое в дальнейшем будут передаваться данные. Сессия начинается с передачи SYN пакета, в ответ на который передается SYN/ACK пакет и подтверждает установление соединения пакет ACK. После этого соединение считается установленным и готовым к передаче данных. Может возникнуть вопрос: «А как же трассируется соединение?». В действительности все довольно просто.

Для всех типов соединений, трассировка проходит практически одинаково. Взгляните на рисунок ниже, где показаны все стадии установления соединения. Как видите, трассировщик, с точки зрения пользователя, фактически не следит за ходом установления соединения. Просто, как только трассировщик «увидел» первый (SYN) пакет, то присваивает ему статус NEW. Как только через трассировщика проходит второй пакет (SYN/ACK), то соединению присваивается статус ESTABLISHED. Почму именно второй пакет? Сейчас разберемся. Строя свой набор правил, вы можете позволить покидать локальную сеть пакетам со статусом NEW и ESTABLISHED, а во входящем трафике пропускать пакеты только со статусом ESTABLISHED и все будет работать прекрасно. И наоборот, если бы трассировщик продолжал считать соединение как NEW, то фактически вам никогда не удалось бы установить соединение с «внешним миром», либо пришлось бы позволить прохождение NEW пакетов в локальную сеть. С точки зрения ядра все выглядит более сложным, поскольку в пространстве ядра TCP соединения имеют ряд промежуточных состояний, недоступных в пространстве пользователя. В общих чертах они соответствуют спецификации RFC 793 - Transmission Control Protocol на странице 21-23. Более подробно эта тема будет рассматриваться чуть ниже.

С точки зрения пользователя все выглядит достаточно просто, однако если посмотреть с точки зрения ядра, то все выглядит несколько сложнее. Рассмотрим порядок изменения состояния соединения в таблице /proc/net/ip_conntrack. После передачи первого пакета SYN.

tcp      6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
     dport=1031 use=1

Теперь запись сообщает о том, что обратно прошел пакет SYN/ACK. На этот раз соединение переводится в состояние SYN_RECV. Это состояние говорит о том, что пакет SYN был благополучно доставлен получателю и в ответ на него пришел пакет-подтверждение (SYN/ACK). Кроме того, механизм определения состояния «увидев» пакеты, следующие в обеих направлениях, снимает флаг [UNREPLIED]. И наконец после передачи заключительного ACK-пакета, в процедуре установления соединения

tcp      6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
     sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
     sport=23 dport=1031 use=1

соединение переходит в состояние ESTABLISHED (установленное). После приема нескольких пакетов через это соединение, к нему добавится флаг [ASSURED] (уверенное).

При закрытии, TCP соединение проходит через следующие состояния:

Как видно из рисунка, соединение не закрывается до тех пор пока не будет передан последний пакет ACK. Обратите внимание — эта картинка описывает нормальный процесс закрытия соединения. Кроме того, если соединение отвергается, то оно может быть закрыто передачей пакета RST (сброс). В этом случае соединение будет закрыто по истечение предопределенного времени.

При закрытии, соединение переводится в состояние TIME_WAIT, продолжительность которого по-умолчанию соответствует 2 минутам, в течение которого еще возможно прохождение пакетов через брандмауэр. Это является своего рода «буферным временем», которое дает возможность пройти пакетам, «увязшим» на том или ином маршрутизаторе (роутере).

Если соединение закрывается по получении пакета RST, то оно переводится в состояние CLOSE. Время ожидания до фактического закрытия соединения по-умолчанию устанавливается равным 10 секунд. Подтверждение на пакеты RST не передается и соединение закрывается сразу же. Кроме того имеется ряд других внутренних состояний. В таблице ниже приводится список возможных внутренних состояний соединения и соответствующие им размеры таймаутов.

Таблица 4-2. Internal states

Состояние	Время ожидания
NONE
ESTABLISHED	5 дней
SYN_SENT	2 минуты
SYN_RECV	60 секунд
FIN_WAIT	2 минуты
TIME_WAIT	2 минуты
CLOSE	10 секунд
CLOSE_WAIT	12 часов
LAST_ACK	30 секунд
LISTEN>	2 минуты

Эти значения могут несколько изменяться от версии к версии ядра, кроме того, они могут быть изменены через интерфейс файловой системы /proc (переменные proc/sys/net/ipv4/netfilter/ip_ct_tcp_*). Значения устанавливаются в сотых долях секунды, так что число 3000 означает 30 секунд.

Обратите внимание на то, что со стороны пользователя, механизм определения состояния никак не отображает состояние флагов TCP пакетов. Как правило — это не всегда хорошо, поскольку состояние NEW присваивается, не только пакетам SYN.
Это качество трассировщика может быть использовано для избыточного файерволлинга (firewalling), но для случая домашней локальной сети, в которой используется только один брандмауэр это очень плохо. Эта проблема более подробно обсуждается в разделе Пакеты со статусом NEW и со сброшенным битом SYN приложения Общие проблемы и вопросы. Альтернативным вариантом решения этой проблемы может служить установка заплаты tcp-window-tracking из patch-o-matic, которая сделает возможным принятие решений в зависимости от значения TCP window.

4.5. UDP соединения¶

По сути своей, UDP соединения не имеют признака состояния. Этому имеется несколько причин, основная из них состоит в том, что этот протокол не предусматривает установления и закрытия соединения, но самый большой недостаток — отсутствие информации об очередности поступления пакетов. Приняв две датаграммы UDP, невозможно сказать точно в каком порядке они были отправлены. Однако, даже в этой ситуации все еще возможно определить состояние соединения. Ниже приводится рисунок того, как выглядит установление соединения с точки зрения трассировщика.

Из рисунка видно, что состояние UDP соединения определяется почти так же как и состояние TCP соединения, с точки зрения из пользовательского пространства. Изнутри же это выглядит несколько иначе, хотя во многом похоже. Для начала посмотрим на запись, появившуюся после передачи первого пакета UDP.

 udp      17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \
     [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 \
     dport=137 use=1

Первое, что мы видим — это название протокола (udp) и его номер (см. /etc/protocols прим. перев.). Третье значение — оставшееся «время жизни» записи в секундах. Далее следуют характеристики пакета, прошедшего через брандмауэр — это адреса и порты отправителя и получателя. Здесь же видно, что это первый пакет в сессии (флаг [UNREPLIED]). И завершают запись адреса и порты отправителя и получателя ожидаемого пакета. Таймаут такой записи по умолчанию составляет 30 секунд.

udp 17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 \
dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 \
dport=137 use=1

После того как сервер «увидел» ответ на первый пакет, соединение считается ESTABLISHED (установленным), единственное отличие от предыдущей записи состоит в отсутствии флага [UNRREPLIED] и, кроме того, таймаут для записи стал равным 180 секундам. После этого может только добавиться флаг [ASSURED] (уверенное соединение), который был описан выше. Флаг [ASSURED] устанавливается только после прохождения некоторого количества пакетов через соединение.

udp 17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 \
dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 \
dport=1025 [ASSURED] use=1

Теперь соединение стало «уверенным». Запись в таблице выглядит практически так же как и в предыдущем примере, за исключением флага [ASSURED]. Если в течение 180 секунд через соединение не пройдет хотя бы один пакет, то запись будет удалена из таблицы. Это достаточно маленький промежуток времени, но его вполне достаточно для большинства применений. «Время жизни» отсчитывается от момента прохождения последнего пакета и при появлении нового, время переустанавливается в свое начальное значение, это справедливо и для всех остальных типов внутренних состояний.

4.6. ICMP соединения¶

Как видно из этого рисунка, сервер выполняет Echo Request (эхо-запрос) к клиенту, который (запрос) распознается брандмауэром как NEW. На этот запрос клиент отвечает пакетом Echo Reply, и теперь пакет распознается как имеющий состояние ESTABLISHED. После прохождения первого пакета (Echo Request) в ip_conntrack появляется запись:

icmp 1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 \
id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 \
type=0 code=0 id=33029 use=1

Эта запись несколько отличается от записей, свойственных протоколам TCP и UDP, хотя точно так же присутствуют и название протокола и время таймаута и адреса передатчика и приемника, но далее появляются три новых поля — type, code и id. Поле type содержит тип ICMP, поле code — код ICMP. Значения типов и кодов ICMP приводятся в приложении Типы ICMP. И последнее поле id содержит идентификатор пакета. Каждый ICMP-пакет имеет свой идентификатор. Когда приемник, в ответ на ICMP-запрос посылает ответ, он подставляет в пакет ответа этот идентификатор, благодаря чему, передатчик может корректно распознать в ответ на какой запрос пришел ответ.

Следующее поле — флаг [UNREPLIED], который встречался нам ранее. Он означает, что прибыл первый пакет в соединении. Завершается запись характеристиками ожидаемого пакета ответа. Сюда включаются адреса отправителя и получателя. Что касается типа и кода ICMP пакета, то они соответствуют правильным значениям ожидаемого пакета ICMP Echo Reply. Идентификатор пакета-ответа тот же, что и в пакете запроса.

Пакет ответа распознается уже как ESTABLISHED. Однако, мы знаем, что после передачи пакета ответа, через это соединение уже ничего не ожидается, поэтому после прохождения ответа через netfilter, запись в таблице трассировщика уничтожается.

В любом случае запрос рассматривается как NEW, а ответ как ESTABLISHED.

Заметьте при этом, что пакет ответа должен совпадать по своим характеристикам (адреса отправителя и получателя, тип, код и идентификатор) с указанными в записи в таблице трассировщика, это справедливо и для всех остальных типов трафика.

ICMP запросы имеют таймаут, по-умолчанию, 30 секунд. Этого времени, в большинстве случаев, вполне достаточно. Время таймаута можно изменить в /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout. (Напоминаю, что переменные типа /proc/sys/net/ipv4/netfilter/ip_ct_* становятся доступны только после установки «заплаты» tcp-window-tracking из patch-o-matic прим. перев.).

Значительная часть ICMP используется для передачи сообщений о том, что происходит с тем или иным UDP или TCP соединением. Всвязи с этим они очень часто распознаются как связанные (RELATED) с существующим соединением. Простым примером могут служить сообщения ICMP Host Unreachable или ICMP Network Unreachable. Они всегда порождаются при попытке соединиться с узлом сети когда этот узел или сеть недоступны, в этом случае последний маршрутизатор вернет соответствующий ICMP пакет, который будет распознан как RELATED. На рисунке ниже показано как это происходит.

В этом примере некоторому узлу передается запрос на соединение (SYN пакет). Он приобретает статус NEW на брандмауэре. Однако, в этот момент времени, сеть оказывается недоступной, поэтому роутер возвращает пакет ICMP Network Unreachable. Трассировщик соединений распознает этот пакет как RELATED, благодаря уже имеющейся записи в таблице, так что пакет благополучно будет передан клиенту, который затем оборвет неудачное соединение. Тем временем, брандмауэр уничтожит запись в таблице, поскольку для данного соединения было получено сообщение об ошибке.

То же самое происходит и с UDP соединениями — если обнаруживаются подобные проблемы. Все сообщения ICMP, передаваемые в ответ на UDP соединение, рассматриваются как RELATED. Взгляните на следующий рисунок.

Датаграмма UDP передается на сервер. Соединению присваивается статус NEW. Однако доступ к сети запрещен (брандмауэром или роутером), поэтому обратно возвращается сообщение ICMP Network Prohibited. Брандмауэр распознает это сообщение как связанное с открытым UDP соединением, присваивает ему статус RELATED и передает клиенту. После чего запись в таблице трассировщика уничтожается, а клиент благополучно обрывает соединение.

4.7. Поведение по-умолчанию¶

В некоторых случаях механизм определения состояния не может распознать протокол обмена и, соответственно, не может выбрать стратегию обработки этого соединения. В этом случае он переходит к заданному по-умолчанию поведению. Поведение по-умолчанию используется, например при обслуживании протоколов NETBLT, MUX и EGP. Поведение по-молчанию во многом схоже с трассировкой UDP соединений. Первому пакету присваивается статус NEW, а всем последующим — статус ESTABLISHED.

При использовании поведения по-умолчанию, для всех пакетов используется одно и то же значение таймаута, которое можно изменить в /proc/sys/net/ipv4/netfilter/ip_ct_generic_timeout. По-умолчанию это значение равно 600 секундам, или 10 минутам В зависимости от типа трафика, это время может меняться, особенно когда соединение устанавливается по спутниковому каналу.

4.8. Трассировка комплексных протоколов¶

Имеется ряд комплексных протоколов, корректная трассировка которых более сложна. Прмером могут служить протоколы ICQ, IRC и FTP. Каждый из этих протоколов несет дополнительную информацию о соединении в области данных пакета. Соответственно корректная трассировка таких соединений требует подключения дополнительных вспомогательных модулей.

В качестве первого примера рассмотрим протокол FTP. Протокол FTP сначала открывает одиночное соединение, которое называется «сеансом управления FTP» (FTP control session). При выполнении команд в пределах этого сеанса, для передачи сопутствующих данных открываются дополнительные порты. Эти соединения могут быть активными или пассивными. При создании активного соединения клент передает FTP серверу номер порта и IP адрес для соединения. Затем клент открывает порт, сервер подключает к заданному порту клиента свой порт с номером 20 (известный как FTP-Data) и передает данные через установленное соединение.

Проблема состоит в том, что брандмауэр ничего не знает об этих дополнительных подключениях, поскольку вся информация о них передается через область данных пакета. Из-за этого брандмауэр не позволит серверу соединиться с указанным портом клиента.

Решение проблемы состоит в добавлении специального вспомогательного модуля трассировки, который отслеживает, специфичную для данного протокола, информацию в области данных пакетов, передаваемых в рамках сеанса управления. При создании такого соединения, вспомогательный модуль корректно воспримет передаваемую информацию и создаст соответствующую запись в таблице трассировщика со статусом RELATED, благодаря чему соединение будет установлено. Рисунок ниже поясняет порядок выполнения подобного соединения.

Пассивный FTP действует противоположным образом. Клиент посылает запрос серверу на получение данных, а сервер возвращает клиенту IP адрес и номер порта для подключения. Клиент подключает свой 20-й порт (FTP-data) к указанному порту сервера и получает запрошенные данные. Если ваш FTP сервер находится за брандмауэром, то вам потребуется этот вспомогательный модуль для того, чтобы сервер смог обслуживать клиентов из Интернет. То же самое касается случая, когда вы хотите ограничить своих пользователей только возможностью подключения к HTTP и FTP серверам в Интернет и закрыть все остальные порты. Рисунок ниже показывает как выполняется пассивное соединение FTP:

Некоторые вспомогательные модули уже включены в состав ядра. Если быть более точным, то в состав ядра включены вспомогательные модули для протоколов FTP и IRC. Если в вашем распоряжении нет необходимого вспомогательного модуля, то вам следует обратиться к patch-o-matic, который содержит большое количество вспомогательных модулей для трассировки таких протоколов, как ntalk или H.323. Если и здесь вы не нашли то, что вам нужно, то у вас есть еще варианты: вы можете обратиться к CVS iptables, если искомый вспомогательный модуль еще не был включен в patch-o-matic, либо можете войти в контакт с разработчиками netfilter и узнать у них — имеется ли подобный модуль и планируется ли он к выпуску. Если и тут вы потерпели неудачу, то наверное вам следует прочитать Rusty Russell’s Unreliable Netfilter Hacking HOW-TO.

Вспомогательные модули могут быть скомпилированы как в виде подгружаемых модулей ядра, так и статически связаны с ядром. Если они скомпилированы как модули, то вы можете загрузить их командой:

modprobe ip_conntrack_*

Обратите внимание на то, что механизм определения состояния не имеет никакого отношения к трансляции сетевых адресов (NAT), поэтому вам может потребоваться большее количество дополнительных модулей, если вы выполняете такую трансляцию. Допустим, что вы выполняете трансляцию адресов и трассировку FTP соединений, тогда вам необходим так же и соответствующий вспомогательный модуль NAT. Имена вспомогательных модулей NAT начинаются с ip_nat_, в соответствии с соглашением об именах. В данном случае модуль называется ip_nat_ftp. Для протокола IRC такой модуль будет называться ip_nat_irc. Тому же самому соглашению следуют и названия вспомогательных модулей трассировщика, например: ip_conntrack_ftp и ip_conntrack_irc.

Глава 5. Сохранение и восстановление больших наборов правил¶

В состав пакета iptables входят две очень удобные утилиты, особенно если вам приходится иметь дело с большими наборами правил. Называются они iptables-save и iptables-restore. Первая из них сохраняет, а вторая восстанавливает наборы правил в/из файла. По своему формату файл с набором правил похож на обычные файлы сценариев командной оболочки (shell), в чем вы сможете убедиться чуть ниже.

5.1. Плюсы¶

Один из плюсов использования утилит iptables-save и iptables-restore состоит в высокой скорости загрузки и сохранения больших наборов правил. Главный недостаток, связанный с установкой наборов правил из сценариев командной оболочки состоит в том, что команда iptables копирует набор правил из пространства ядра в пространство пользователя, вставляет, добавляет или изменяет правило и, наконец, весь набор правил копируется обратно в пространство ядра. Эта последовательность действий выполняется для каждого правила, которое вставляется или изменяется в наборе правил.

Эта проблема легко решается с помощью iptables-save и iptables-restore Утилита iptables-save записывает набор правил в обычный текстовый файл в особом формате. Утилита iptables-restore загружает набор правил из файла. Главное преимущество этих утилит состоит в том, что они производят сохранение/восстановление всего набора правил за одно обращение. iptables-save «в один присест» получает из пространства ядра и записывает в файл весь набор правил, а iptables-restore загружает из файла и переписывает за одно обращение в пространство ядра набор правил для каждой таблицы. Или другими словами — вместо того, чтобы обращаться огромное число раз к ядру для того чтобы получить набор правил, а затем опять записать его в пространство ядра не меньшее число раз, можно просто сохранить набор правил в файл, а затем загружать его из файла, при этом число перемещений наборов в ядро будет зависеть только от числа используемых таблиц.

Вы уже наверняка поняли, что эти утилиты могут представлять для вас интерес, особенно если вам приходится загружать огромные наборы правил. Однако использование этих утилит имеет и свои отрицательные стороны, которые мы рассмотрим в следующем разделе.

5.2. И минусы¶

У вас может сложиться впечатление, что iptables-restore может обрабатывать своего рода сценарии. Пока не может и вероятнее всего — никогда не сможет. В этом и состоит главный недостаток iptables-restore. Чтобы было более понятно — представьте себе случай, когда брандмауэр получает динамический IP-адрес и вы хотите вставить его значение в свои правила во время загрузки системы. Решить эту проблему с помощью iptables-restore практически невозможно.

Как одно из решений можно предложить написать небольшой скрипт, который определяет значение IP-адреса и затем вставляет его в набор правил (например, с помощью sed) на место некоторого ключевого слова. Здесь вам потребуется создать временный файл, в котором производятся изменения и который затем загружается с помощью iptables-restore. Однако такой вариант решения порождает свои проблемы — вам придется отказаться от утилиты iptables-save поскольку она может затереть, созданную вручную, заготовку файла с правилами для iptables-restore. Вобщем — довольно неуклюжее решение.

Еще один вариант — хранить в файле для iptables-restore только статические правила, а затем с помощью небольшого скрипта добавлять правила с динамическими параметрами. Конечно же вы уже поняли, что это решение такое же неуклюжее как и первое. Вам придется смириться с тем, что iptables-restore не очень хорошо подходит для случая с динамически назначаемым IP-адресом и вообще для случаев, когда вам потребуется динамически изменять набор правил в зависимости от конфигурации системы и т.п..

Еще один недостаток iptables-restore и iptables-save в том, что их функциональность не всегда соответствует описанной. Проблема состоит в том, что не многие пользуются этими утилитами, еще меньше людей вовлечено в процесс поиска ошибок в этих программах. Поэтому, при использовании некоторых, вновь появившихся, критериев или действий вы можете столкнуться с неожиданным поведением своих правил. Несмотря на возможное существование некоторых проблем, я все же настоятельно рекомендую к использованию эти два инструмента, которые прекрасно работают в большинстве случаев, исключение могут составлять лишь некоторые новые критерии и действия.

5.3. iptables-save¶

Утилита iptables-save, как я уже упоминал, предназначена для сохранения текущего набора правил в файл, который затем может быть использован утилитой iptables-restore. Эта команда очень проста в использовании и имеет всего два аргумента.

iptables-save [-c] [-t table]

Первый аргумент -c (допустимо использовать более длинный вариант --counters) заставляет iptables-save сохранить знчения счетчиков байт и пакетов. Это делает возможным рестарт брандмауэра без потери счетчиков, которые могут использоваться для подсчета статистики. По-умолчанию, при запуске без ключа -с, сохранение счетчиков не производится.

С помощью ключа -t (более длинный вариант --table) можно указать имя таблицы для сохранения. Если ключ -t не задан, то сохраняются все таблицы. Ниже приведен пример работы команды iptables-save в случае, когда набор не содержит ни одного правила.

# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
*filter
:INPUT ACCEPT [404:19766]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [530:43376]
COMMIT
# Completed on Wed Apr 24 10:19:17 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
*mangle
:PREROUTING ACCEPT [451:22060]
:INPUT ACCEPT [451:22060]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [594:47151]
:POSTROUTING ACCEPT [594:47151]
COMMIT
# Completed on Wed Apr 24 10:19:17 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [3:450]
:OUTPUT ACCEPT [3:450]
COMMIT
# Completed on Wed Apr 24 10:19:17 2002

Строки, начинающиеся с символа #, являются комментариями. Имена таблиц начинаются с символа * (звездочка), например: *mangle. После каждого имени таблицы следуют описания цепочек и правил. Описания цепочек записываются в формате :
<chain-name> <chain-policy> [<packet-counter>:<byte-counter>],
где <chain-name> — это название цепочки (например PREROUTING), <chain-policy> — политика по-умолчанию (например ACCEPT). Завершают описание цепочки значения счетчиков пакетов и байт, те самые счетчики, которые вы получите в результате выполнения команды iptables -L -v. Описание каждой таблицы завершает ключевое слово COMMIT, которое означает, что в этой точке набор правил для данной таблицы будет передан в пространство ядра.

Пример выше показал как выглядит содержимое пустого набора правил, сохраненного утилитой iptables-save. Ниже показан результат сохранения небольшого набора правил (Iptables-save ruleset):

# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*filter
:INPUT DROP [1:229]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
[0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[0:0] -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
[0:0] -A FORWARD -i eth1 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
[0:0] -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Wed Apr 24 10:19:55 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*mangle
:PREROUTING ACCEPT [658:32445]
:INPUT ACCEPT [658:32445]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [891:68234]
:POSTROUTING ACCEPT [891:68234]
COMMIT
# Completed on Wed Apr 24 10:19:55 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*nat
:PREROUTING ACCEPT [1:229]
:POSTROUTING ACCEPT [3:450]
:OUTPUT ACCEPT [3:450]
[0:0] -A POSTROUTING -o eth0 -j SNAT --to-source 195.233.192.1
COMMIT
# Completed on Wed Apr 24 10:19:55 2002

Из примера виден результат действия аргумента -c — перед каждым правилом и в строке описания каждой цепочки имеются числа, отображающие содержимое счетчиков пакетов и байт. Сразу замечу, что набор правил утилита iptables-save выдает на стандартный вывод, поэтому, при сохранении набора в файл команда должна выглядеть примерно так:

iptables-save -c > /etc/iptables-save

Эта команда запишет весь набор правил, вместе с содержимым счетчиков, в файл с именем /etc/iptables-save.

5.4. iptables-restore¶

Утилита iptables-restore используется для восстановления (загрузки) набора правил, который ранее был сохранен утилитой iptables-save. Набор правил утилита получает со стандартного ввода и не может загружать его из файла напрямую. Команда имеет следующий синтаксис:

iptables-restore [-c] [-n]

Ключ -c (более длинный вариант --counters) заставляет восстанавливать значения счетчиков.

Указание ключа -n (более длинный вариант --noflush) сообщает iptables-restore о том, что правила должны быть добавлены к имеющимся. По-умолчанию утилита iptables-restore (без ключа -n) очистит содержимое таблиц и цепочек перед загрузкой нового набора правил.

Для загрузки набора правил утилитой iptables-restore из файла можно предложить несколько вариантов, но наиболее употребимый:

cat /etc/iptables-save | iptables-restore -c

В результате выполнения этой команды содержимое файла /etc/iptables-save будет прочитано утилитой cat и перенаправленно на стандартный ввод утилиты iptables-restore. Можно было бы привести еще целый ряд команд, с помощью которых можно организовать загрузку набора правил из файла, но это выходит за рамки темы, поэтому оставлю читателю возможность самому найти более удобный для него вариант.

После исполнения этой команды набор правил должен загрузиться и все должно работать. Если это не так, то скорее всего вы допустили ошибку при наборе команды.

Глава 6. Как строить правила¶

В данной главе будет обсуждаться порядок построения собственных правил для iptables. Каждая строка, которую вы вставляете в ту или иную цепочку, должна содержать отдельное правило. Мы так же обсудим основные критерии и действия (targets) и порядок создания своих собственных действий (т.е. подцепочек правил).

6.1. Основы¶

Как уже говорилось выше, каждое правило — это строка, содержащая в себе критерии определяющие, подпадает ли пакет под заданное правило, и действие, которое необходимо выполнить в случае выполнения критерия. В общем виде правила записываются примерно так:
iptables [-t table] command [match] [target/jump]

Нигде не утверждается, что описание действия (target/jump) должно стоять последним в строке, однако, такая нотация более удобочитаема. Как бы то ни было, но чаще всего вам будет встречаться именно такой способ записи правил.

Если в правило не включается спецификатор [-t table], то по умолчанию предполагается использование таблицы filter, если же предполагается использование другой таблицы, то это требуется указать явно. Спецификатор таблицы так же можно указывать в любом месте строки правила, однако более или менее стандартом считается указание таблицы в начале правила.

Далее, непосредственно за именем таблицы, должна стоять команда. Если спецификатора таблицы нет, то команда всегда должна стоять первой. Команда определяет действие iptables, например: вставить правило, или добавить правило в конец цепочки, или удалить правило и т.п.

Раздел match задает критерии проверки, по которым определяется подпадает ли пакет под действие этого правила или нет. Здесь мы можем указать самые разные критерии — IP-адрес источника пакета или сети, IP-адрес места назначения,порт, протокол, сетевой интерфейс и т.д. Существует множество разнообразных критериев, но об этом — несколько позже.

И наконец target указывает, какое действие должно быть выполнено при условии выполнения критериев в правиле. Здесь можно заставить ядро передать пакет в другую цепочку правил, «сбросить» пакет и забыть про него, выдать на источник сообщение об ошибке и т.п.

6.2. Таблицы¶

Опция -t указывает на используемую таблицу. По умолчанию используется таблица filter. С ключом -t применяются следующие опции.

Таблица 6-1. Таблицы

Состояние	Описание
nat	Таблица nat используется главным образом для преобразования сетевых адресов (`Network Address Translation`). Через эту таблицу проходит только первый пакет из потока. Преобразования адресов автоматически применяется ко всем последующим пакетам. Это один из факторов, исходя из которых мы не должны осуществлять какую-либо фильтрацию в этой таблице. Цепочка `PREROUTING` используется для внесения изменений в пакеты на входе в брандмауэр. Цепочка `OUTPUT` используется для преобразования адресов в пакетах, созданных приложениями внутри брандмауэра, перед принятием решения о маршрутизации. И последняя цепочка в этой таблице — `POSTROUTING`, которая используется для преобразования пакетов перед выдачей их в сеть.
mangle	Эта таблица используется для внесения изменений в заголовки пакетов. Примером может служить изменение поля `TTL, TOS` или `MARK`. Важно: в действительности поле `MARK` не изменяется, но в памяти ядра заводится структура, которая сопровождает данный пакет все время его прохождения через брандмауэр, так что другие правила и приложения на данном брандмауэре (и только на данной брандмауэре) могут использовать это поле в своих целях. Таблица имеет пять цепочек `PREROUTING, POSTROUTING, INPUT, OUTPUT` и `FORWARD`. `PREROUTING` используется для внесения изменений на входе в брандмауэр, перед принятием решения о маршрутизации. `POSTROUTING` используется для внесения изменений на выходе из брандмауэра, после принятия решения о маршрутизации. `INPUT` — для внесения изменений в пакеты перед тем как они будут переданы локальному приложению внутри брандмауэра. `OUTPUT` — для внесения изменений в пакеты, поступающие от приложений внутри брандмауэра. `FORWARD` — для внесения изменений в транзитные пакеты после первого принятия решения о ипршрутизации, но перед последним принятием решения о ипршрутизации. Замечу, что таблица `mangl@e ни в коем случае не должна использоваться для преобразования сетевых адресов или маскарадинга` (Network Address Translation, Masquerading)`, поскольку для этих целей имеется таблица @nat`.
filter	Таблица `filter` используется главным образом для фильтрации пакетов. Для примера, здесь мы можем выполнить `DROP`, `LOG, ACCEPT` или `REJECT` без каких либо ограничений, которые имеются в других таблицах. Имеется три встроенных цепочки. Первая — `FORWARD`, используемая для фильтрации пакетов, идущих транзитом через брандмауэр. Цепочку `INPUT` проходят пакеты, которые предназначены локальным приложениям (брандмауэру). И цепочка `OUTPUT` — используется для фильтрации исходящих пакетов, сгенерированных приложениями на самом брандмауэре.

Выше мы рассмотрели основные отличия трех имеющихся таблиц. Каждая из них должна использоваться только в своих целях, и вы должны это понимать. Нецелевое использование таблиц может привести к ослаблению защиты брандмауэра и сети, находящейся за ним. Позднее, в главе Порядок прохождения таблиц и цепочек, мы подробнее остановимся на этом.

6.3. Команды¶

Ниже приводится список команд и правила их использования. Посредством команд мы сообщаем iptables, что мы предполагаем сделать. Обычно предполагается одно из двух действий — добавление нового правила в цепочку или удаление существующего правила из той или иной таблицы. Далее приведены команды, которые используются в iptables.

Таблица 6-2. Команды

Команда	`-A, --append`
Пример	iptables -A INPUT …
Описание	Добавляет новое правило в конец заданной цепочки.
Команда	`-D, --delete`
Пример	iptables -D INPUT —dport 80 -j DROP, iptables -D INPUT 1
Описание	Удаление правила из цепочки. Команда имеет два формата записи, первый — когда задается критерий сравнения с опцией `-D` (см. первый пример), второй — порядковый номер правила. Если задается критерий сравнения, то удаляется правило, которое имеет в себе этот критерий, если задается номер правила, то будет удалено правило с заданным номером. Счет правил в цепочках начинается с 1.
Команда	`-R, --replace`
Пример	iptables -R INPUT 1 -s 192.168.0.1 -j DROP
Описание	Эта команда заменяет одно правило другим. В основном она используется во время отладки новых правил.
Команда	`-I, --insert`
Пример	iptables -I INPUT 1 —dport 80 -j ACCEPT
Описание	Вставляет новое правило в цепочку. Число, следующее за именем цепочки указывает номер правила, перед которым нужно вставить новое правило, другими словами число задает номер для вставляемого правила. В примере выше, указывается, что данное правило должно быть 1-м в цепочке `INPUT`.
Команда	`-L, --list`
Пример	iptables -L INPUT
Описание	Вывод списка правил в заданной цепочке, в данном примере предполагается вывод правил из цепочки `INPUT`. Если имя цепочки не указывается, то выводится список правил для всех цепочек. Формат вывода зависит от наличия дополнительных ключей в команде, например `-n, -v`, и пр.
Команда	`-F, --flush`
Пример	iptables -F INPUT
Описание	Сброс (удаление) всех правил из заданной цепочки (таблицы). Если имя цепочки и таблицы не указывается, то удаляются все правила, во всех цепочках. (Хочется от себя добавить, что если не указана таблица ключом `-t (--table)`, то очистка цепочек производится только в таблице `filter`, прим. перев. )
Команда	`-Z, --zero`
Пример	iptables -Z INPUT
Описание	Обнуление всех счетчиков в заданной цепочке. Если имя цепочки не указывается, то подразумеваются все цепочки. При использовании ключа `-v` совместно с командой `-L`, на вывод будут поданы и состояния счетчиков пакетов, попавших под действие каждого правила. Допускается совместное использование команд `-L` и `-Z`. В этом случае будет выдан сначала список правил со счетчиками, а затем произойдет обнуление счетчиков.
Команда	`-N, --new-chain`
Пример	iptables -N allowed
Описание	Создается новая цепочка с заданным именем в заданной таблице В выше приведенном примере создается новая цепочка с именем `allowed`. Имя цепочки должно быть уникальным и не должно совпадать с зарезервированными именами цепочек и действий (такими как `DROP, REJECT` и т.п.)
Команда	`-X, --delete-chain`
Пример	iptables -X allowed
Описание	Удаление заданной цепочки из заданной таблицы. Удаляемая цепочка не должна иметь правил и не должно быть ссылок из других цепочек на удаляемую цепочку. Если имя цепочки не указано, то будут удалены все цепочки заданной таблице кроме встроенных.
Команда	`-P, --policy`
Пример	iptables -P INPUT DROP
Описание	Задает политику по-умолчанию для заданной цепочки. Политика по-умолчанию определяет действие, применяемое к пакетам не попавшим под действие ни одного из правил в цепочке. В качестве политики по умолчанию допускается использовать `DROP` и `ACCEPT`.
Команда	`-E, --rename-chain`
Пример	iptables -E allowed disallowed
Описание	Команда `-E` выполняет переименование пользовательской цепочки. В примере цепочка `allowed` будет переименована в цепочку `disallowed`. Эти переименования не изменяют порядок работы, а носят только косметический характер.

Команда должна быть указана всегда. Список доступных команд можно просмотреть с помощью команды iptables -h или, что тоже самое, iptables —help. Некоторые команды могут использоваться совместно с дополнительными ключами. Ниже приводится список дополнительных ключей и описывается результат их действия. При этом заметьте, что здесь не приводится дополнительных ключей, которые используются при построении критериев (matches) или действий (targets). Эти опции мы будем обсуждать далее.

Таблица 6-3. Дополнительные ключи

Ключ	`-v, --verbose`
Команды, с которыми используется	`--list, --append, --insert, --delete, --replace`
Описание	Используется для повышения информативности вывода и, как правило, используется совместно с командой `--list`. В случае использования с командой `--list`, в вывод этой команды включаются так же имя интерфейса, счетчики пакетов и байт для каждого правила. Формат вывода счетчиков предполагает вывод кроме цифр числа еще и символьные множители K (x1000), M (x1,000,000) и G (x1,000,000,000). Для того, чтобы заставить команду `--list` выводить полное число (без употребления множителей) требуется применять ключ `-x`, который описан ниже. Если ключ `-v, --verbose` используется с командами `--append, --insert, --delete` или `--replace`, то будет выведен подробный отчет о произведенной операции.
Ключ	`-x, --exact`
Команды, с которыми используется	`--list`
Описание	Для всех чисел в выходных данных выводятся их точные значения без округления и без использования множителей K, M, G. Этот ключ используется только с командой `--list` и не применим с другими командами.
Ключ	`-n, --numeric`
Команды, с которыми используется	`--list`
Описание	Заставляет `iptables` выводить IP-адреса и номера портов в числовом виде предотвращая попытки преобразовать их в символические имена. Данный ключ используется только с командой `--list`.
Ключ	`--line-numbers`
Команды, с которыми используется	`--list`
Описание	Ключ `--line-numbers` включает режим вывода номеров строк при отображении списка правил командой `--list`. Номер строки соответствует позиции правила в цепочке. Этот ключ используется только с командой `--list`.
Ключ	`-c, --set-counters`
Команды, с которыми используется	`--insert, --append, --replace`
Описание	Этот ключ используется для установки начального значения счетчиков пакетов и байт в заданное значение при создании нового правила. Например, ключ `--set-counters` 20 4000 установит счетчик пакетов = 20, а счетчик байт = 4000.
Ключ	`--modprobe`
Команды, с которыми используется	Все
Описание	Ключ `--modprobe` определяет команду загрузки модуля ядра. Данный ключ может использоваться в случае, когда модули ядра находится вне пути поиска (`search path`). Этот ключ может использоваться с любой командой.

6.4. Критерии¶

Здесь мы подробнее остановимся на критериях выделения пакетов. Я разбил все критерии на пять групп. Первая — общие критерии которые могут использоваться в любых правилах. Вторая — TCP критерии которые применяются только к TCP пакетам. Третья — UDP критерии которые применяются только к UDP пакетам. Четвертая — ICMP критерии для работы с ICMP пакетами. И наконец пятая — специальные критерии, такие как state, owner, limit и пр.

6.4.1. Общие критерии

Здесь мы рассмотрим Общие критерии. Общие критерии допустимо употреблять в любых правилах, они не зависят от типа протокола и не требуют подгрузки модулей расширения. К этой группе я умышленно отнес критерий --protocol несмотря на то, что он используется в некоторых специфичных от протокола расширениях. Например, мы решили использовать TCP критерий, тогда нам необходимо будет использовать и критерий --protocol которому в качестве дополнительного ключа передается название протокола — TCP. Однако критерий --protocol сам по себе является критерием, который используется для указания типа протокола.

Таблица 6-4. Общие критерии

Критерий	`-p, --protocol`
Пример	iptables -A INPUT -p tcp
Описание	Этот критерий используется для указания типа протокола. Примерами протоколов могут быть `TCP, UDP` и `ICMP`. Список протоколов можно посмотреть в файле `/etc/protocols`. Прежде всего, в качестве имени протокола в данный критерий можно передавать один из трех вышеупомянутых протоколов, а также ключевое слово `ALL`. В качестве протокола допускается передавать число — номер протокола, так например, протоколу `ICMP` соответствует число 1, `TCP` — 6 и `UDP` — 17. Соответствия между номерами протоколов и их именами вы можете посмотреть в файле `/etc/protocols`, который уже упоминался. Критерию может передаваться и список протоколов, разделенных запятыми, например так: `udp,tcp` (Хотя автор и указывает на возможность передачи списка протоколов, тем не менее вам врят ли удастся это сделать! Кстати, man iptables явно оговаривает, что в данном критерии может быть указан только один протокол. Может быть это расширение имеется в `patch-o-matic`? прим. перев.) Если данному критерию передается числовое значение 0, то это эквивалентно использованию спецификатора `ALL`, который подразумевается по умолчанию, когда критерий `--protocol` не используется. Для логической инверсии критерия, перед именем протокола (списком протоколов) используется символ `!`, например `--protocol ! tcp` подразумевает пакеты протоколов, `UDP` и `ICMP`.
Критерий	`-s, --src, --source`
Пример	iptables -A INPUT -s 192.168.1.1
Описание	IP-адрес(а) источника пакета. Адрес источника может указываться так, как показано в примере, тогда подразумевается единственный IP-адрес. А можно указать адрес в виде `address/mask`, например как `192.168.0.0/255.255.255.0`, или более современным способом `192.168.0.0/24`, т.е. фактически определяя диапазон адресов Как и ранее, символ `!`, установленный перед адресом, означает логическое отрицание, т.е. `--source ! 192.168.0.0/24` означает любой адрес кроме адресов `192.168.0.x.`
Критерий	`-d, --dst, --destination`
Пример	iptables -A INPUT -d 192.168.1.1
Описание	IP-адрес(а) получателя. Имеет синтаксис схожий с критерием `--source`, за исключением того, что подразумевает адрес места назначения. Точно так же может определять как единственный IP-адрес, так и диапазон адресов. Символ `!` используется для логической инверсии критерия.
Критерий	`-i, --in-interface`
Пример	iptables -A INPUT -i eth0
Описание	Интерфейс, с которого был получен пакет. Использование этого критерия допускается только в цепочках `INPUT`, `FORWARD` и `PREROUTING`, в любых других случаях будет вызывать сообщение об ошибке. При отсутствии этого критерия предполагается любой интерфейс, что равносильно использованию критерия `-i +`. Как и прежде, символ `!` инвертирует результат совпадения. Если имя интерфейса завершается символом `+`, то критерий задает все интерфейсы, начинающиеся с заданной строки, например `-i PPP+` обозначает любой `PPP` интерфейс, а запись `-i ! eth+` — любой интерфейс, кроме любого `eth`.
Критерий	`-o, --out-interface`
Пример	iptables -A FORWARD -o eth0
Описание	Задает имя выходного интерфейса. Этот критерий допускается использовать только в цепочках `OUTPUT, FORWARD` и `POSTROUTING`, в противном случае будет генерироваться сообщение об ошибке. При отсутствии этого критерия предполагается любой интерфейс, что равносильно использованию критерия `-o +`. Как и прежде, символ `!` инвертирует результат совпадения. Если имя интерфейса завершается символом `+`, то критерий задает все интерфейсы, начинающиеся с заданной строки, например `-o eth+` обозначает любой `eth` интерфейс, а запись `-o ! eth+` — любой интерфейс, кроме любого `eth`.
Критерий	`-f, --fragment`
Пример	iptables -A INPUT -f
Описание	Правило распространяется на все фрагменты фрагментированного пакета, кроме первого, сделано это потому, что нет возможности определить исходящий/входящий порт для фрагмента пакета, а для `ICMP`-пакетов определить их тип. С помощью фрагментированных пакетов могут производиться атаки на ваш брандмауэр, так как фрагменты пакетов могут не отлавливаться другими правилами. Как и раньше, допускается использования символа `!` для инверсии результата сравнения. только в данном случае символ `!` должен предшествовать критерию `-f`, например `! -f`. Инверсия критерия трактуется как «все первые фрагменты фрагментированных пакетов и/или нефрагментированные пакеты, но не вторые и последующие фрагменты фрагментированных пакетов».

6.4.2. Неявные критерии

В этом разделе мы рассмотрим неявные критерии, точнее, те критерии, которые подгружаются неявно и становятся доступны, например при указании критерия --protocol tcp. На сегодняшний день существует три автоматически подгружаемых расширения, это TCP критерии, UDP критерии и ICMP критерии (при построении своих правил я столкнулся с необходимостью явного указания ключа -m tcp, т.е. о неявности здесь говорить не приходится, поэтому будьте внимательнее при построении своих правил, если что-то не идет — пробуйте явно указывать необходимое расширение. прим. перев.). Загрузка этих расширений может производиться и явным образом с помощью ключа -m, -match, например -m tcp.

6.4.2.1. TCP критерии

Этот набор критериев зависит от типа протокола и работает только с TCP пакетами. Чтобы использовать их, вам потребуется в правилах указывать тип протокола --protocol tcp. Важно: критерий --protocol tcp обязательно должен стоять перед специфичным критерием. Эти расширения загружаются автоматически как для tcp протокола, так и для udp и icmp протоколов. (О неявной загрузке расширений я уже упоминал выше прим. перев.).

Таблица 6-5. TCP критерии

Критерий	`--sport, --source-port`
Пример	iptables -A INPUT -p tcp —sport 22
Описание	Исходный порт, с которого был отправлен пакет. В качестве параметра может указываться номер порта или название сетевой службы. Соответствие имен сервисов и номеров портов вы сможете найти в файле `/etc/services`. При указании номеров портов правила отрабатывают несколько быстрее. однако это менее удобно при разборе листингов скриптов. Если же вы собираетесь создавать значительные по объему наборы правил, скажем порядка нескольких сотен и более, то тут предпочтительнее использовать номера портов. Номера портов могут задаваться в виде интервала из минимального и максимального номеров, например `--source-port 22:80`. Если опускается минимальный порт, т.е. когда критерий записывается как `--source-port :80`, то в качестве начала диапазона принимается число 0. Если опускается максимальный порт, т.е. когда критерий записывается как `--source-port 22:`, то в качестве конца диапазона принимается число 65535. Допускается такая запись `--source-port 80:22`, в этом случае iptables поменяет числа 22 и 80 местами, т.е. подобного рода запись будет преобразована в `--source-port 22:80`. Как и раньше, символ `!` используется для инверсии. Так критерий `--source-port ! 22` подразумевает любой порт, кроме `22`. Инверсия может применяться и к диапазону портов, например `--source-port ! 22:80`. За дополнительной информацией обращайтесь к описанию критерия `multiport`.
Критерий	`--dport, --destination-port`
Пример	iptables -A INPUT -p tcp —dport 22
Описание	Порт или диапазон портов, на который адресован пакет. Аргументы задаются в том же формате, что и для `--source-port`.
Критерий	`--tcp-flags`
Пример	iptables -p tcp —tcp-flags SYN,FIN,ACK SYN
Описание	Определяет маску и флаги tcp-пакета. Пакет считается удовлетворяющим критерию, если из перечисленных флагов в первом списке в единичное состояние установлены флаги из второго списка. Так для вышеуказанного примера под критерий подпадают пакеты у которых флаг `SYN` установлен, а флаги `FIN` и `ACK` сброшены. В качестве аргументов критерия могут выступать флаги `SYN, ACK, FIN, RST, URG, PSH,` а так же зарезервированные идентификаторы `ALL` и `NONE`. `ALL` — значит ВСЕ флаги и `NONE` — НИ ОДИН флаг. Так, критерий `--tcp-flags ALL NONE` означает — «все флаги в пакете должны быть сброшены». Как и ранее, символ `!` означает инверсию критерия Важно: имена флагов в каждом списке должны разделяться запятыми, пробелы служат для разделения списков.
Критерий	`--syn`
Пример	iptables -p tcp —syn
Описание	Критерий `--syn` является по сути реликтом, перекочевавшим из `ipchains`. Критерию соответствуют пакеты с установленным флагом `SYN` и сброшенными флагами `ACK` и `FIN`. Этот критерий аналогичен критерию `--tcp-flags SYN,ACK,FIN SYN`. Такие пакеты используются для открытия соединения `TCP`. Заблокировав такие пакеты, вы надежно заблокируете все входящие запросы на соединение, однако этот критерий не способен заблокировать исходящие запросы на соединение. Как и ранее, допускается инвертирование критерия символом `!`. Так критерий `! --syn` означает — «все пакеты, не являющиеся запросом на соединение», т.е. все пакеты с установленными флагами `FIN` или `ACK`.
Критерий	`--tcp-option`
Пример	iptables -p tcp —tcp-option 16
Описание	Удовлетворяющим условию данного критерия будет будет считаться пакет, `TCP` параметр которого равен заданному числу. `TCP Option` — это часть заголовка пакета. Она состоит из 3 различных полей. Первое 8-ми битовое поле содержит информацию об опциях, используемых в данном соединении. Второе 8-ми битовое поле содержит длину поля опций. Если следовать стандартам до конца, то следовало бы реализовать обработку всех возможных вариантов, однако, вместо этого мы можем проверить первое поле и в случае, если там указана неподдерживаемая нашим брандмауэром опция, то просто перешагнуть через третье поле (длина которого содержится во втором поле). Пакет, который не будет иметь полного `TCP` заголовка, будет сброшен автоматически при попытке изучения его `TCP` параметра. Как и ранее, допускается использование флага инверсии условия `!`. Дополнительную информацию по `TCP Options` вы сможете найти на Internet Engineering Task Force

6.4.2.2. UDP критерии

В данном разделе будут рассматриваться критерии, специфичные только для протокола UDP. Эти расширения подгружаются автоматически при указании типа протокола --protocol udp. Важно отметить, что пакеты UDP не ориентированы на установленное соединение, и поэтому не имеют различных флагов которые дают возможность судить о предназначении датаграмм. Получение UDP пакетов не требует какого либо подтверждения со стороны получателя. Если они потеряны, то они просто потеряны (не вызывая передачу ICMP сообщения об ошибке). Это предполагает наличие значительно меньшего числа дополнительных критериев, в отличие от TCP пакетов. Важно: Хороший брандмауэр должен работать с пакетами любого типа, UDP или ICMP, которые считаются не ориентированными на соединение, так же хорошо как и с TCP пакетами. Об этом мы поговорим позднее, в следующих главах.

Таблица 6-6. UDP критерии

Критерий	`--sport, --source-port`
Пример	iptables -A INPUT -p udp —sport 53
Описание	Исходный порт, с которого был отправлен пакет. В качестве параметра может указываться номер порта или название сетевой службы. Соответствие имен сервисов и номеров портов вы сможете найти в файле services.txt . При указании номеров портов правила отрабатывают несколько быстрее. однако это менее удобно при разборе листингов скриптов. Если же вы собираетесь создавать значительные по объему наборы правил, скажем порядка нескольких сотен и более, то тут предпочтительнее использовать номера портов. Номера портов могут задаваться в виде интервала из минимального и максимального номеров, например `--source-port 22:80`. Если опускается минимальный порт, т.е. когда критерий записывается как `--source-port :80`, то в качестве начала диапазона принимается число 0. Если опускается максимальный порт, т.е. когда критерий записывается как `--source-port 22:` , то в качестве конца диапазона принимается число `65535`. Допускается такая запись `--source-port 80:22`, в этом случае `iptables` поменяет числа 22 и 80 местами, т.е. подобного рода запись будет преобразована в `--source-port 22:80`. Как и раньше, символ `!` используется для инверсии. Так критерий `--source-port ! 22` подразумевает любой порт, кроме 22. Инверсия может применяться и к диапазону портов, например `--source-port ! 22:80`.
Критерий	`--dport, --destination-port`
Пример	iptables -A INPUT -p udp —dport 53
Описание	Порт, на который адресован пакет. Формат аргументов полностью аналогичен принятому в критерии `--source-port`.

6.4.2.3. ICMP критерии

Этот протокол используется, как правило, для передачи сообщений об ошибках и для управления соединением. Он не является подчиненным IP протоколу, но тесно с ним взаимодействует, поскольку помогает обрабатывать ошибочные ситуации. Заголовки ICMP пакетов очень похожи на IP заголовки, но имеют и отличия. Главное свойство этого протокола заключается в типе заголовка, который содержит информацию о том, что это за пакет. Например, когда мы пытаемся соединиться с недоступным хостом, то мы получим в ответ сообщение ICMP host unreachable. Полный список типов ICMP сообщений, вы можете посмотреть в приложении Типы ICMP. Существует только один специфичный критерий для ICMP пакетов. Это расширение загружается автоматически, когда мы указываем критерий --protocol icmp. Заметьте, что для проверки ICMP пакетов могут употребляться и общие критерии, поскольку известны и адрес источника и адрес назначения и пр.

Таблица 6-7. ICMP критерии

Критерий	`--icmp-type`
Пример	iptables -A INPUT -p icmp —icmp-type 8
Описание	Тип сообщения `ICMP` определяется номером или именем. Числовые значения определяются в `RFC 792`. Чтобы получить список имен `ICMP` значений выполните команду iptables —protocol icmp —help, или посмотрите приложение Типы ICMP. Как и ранее, символ `!` инвертирует критерий, например `--icmp-type ! 8`.

6.4.3.1. Критерий Limit

Должен подгружаться явно ключом -m limit. Прекрасно подходит для правил, производящих запись в системный журнал (logging) и т.п. Добавляя этот критерий, мы тем самым устанавливаем предельное число пакетов в единицу времени, которое способно пропустить правило. Можно использовать символ ! для инверсии, например -m limit ! --limit 5/s. В этом случае подразумевается, что пакеты будут проходить правило только после превышения ограничения.

Более наглядно этот критерий можно представить себе как некоторую емкость с выпускным отверстием, через которое проходит определенное число пакетов за единицу времени (т.е. скорость «вытекания»). Скорость «вытекания» как раз и определяет величина --limit. Величина --limit-burst задает общий «объем емкости». А теперь представим себе правило --limit 3/minute --limit-burst 5, тогда после поступления 5 пакетов (за очень короткий промежуток времени), емкость «наполнится» и каждый последующий пакет будет вызывать «переполнение» емкости, т.е. «срабатывание» критерия. Через 20 секунд «уровень» в емкости будет понижен (в соответствии с величиной --limit), таким образом она готова будет принять еще один пакет, не вызывая «переполнения» емкости, т.е. срабатывания критерия.

Рассмотрим еще подробнее

Предположим наличие правила, содержащего критерий -m limit --limit 5/second --limit-burst 10. Ключ limit-burst установил объем «емкости» равный 10-ти. Каждый пакет, который подпадает под указанное правило, направляется в эту емкость.
Допустим, в течение 1/1000 секунды, мы получили 10 пакетов, тогда с получением каждого пакета «уровень» в «емкости» будет возрастать: 1-2-3-4-5-6-7-8-9-10.
Емкость наполнилась. Теперь пакеты, подпадающие под наше ограничительное правило, больше не смогут попасть в эту «емкость» (там просто нет места), поэтому они (пакеты) пойдут дальше по набору правил, пока не будут явно восприняты одним из них, либо подвергнутся политике по-умолчанию.
Каждые 1/5 секунды «уровень» в воображаемой емкости снижается на 1, и так до тех пор, пока «емкость» не будет опустошена. Через секунду, после приема 10-ти пакетов «емкость» готова будет принять еще 5 пакетов.
Само собой разумеется, что «уровень» в «емкости» возрастает на 1 с каждым вновь пришедшим пакетом.

От переводчика: Очень долгое время мое понимание критериев limit находилось на интуитивном уровне, пока Владимир Холманов (снимаю шляпу в глубочайшем поклоне) не объяснил мне просто и понятно его суть. Постараюсь передать его пояснения:

Расширение -m limit подразумевает наличие ключей --limit и --limit-burst. Если вы не указываете эти ключи, то они принимают значение по-умолчанию.
Ключ --limit-burst — это максимальное значение счетчика пакетов, при котором срабатывает ограничение.
Ключ --limit — это скорость, с которой счетчик burst limit «откручивается назад».

Принцип, который просто реализуется на C и широко используется во многих алгоритмах-ограничителях.

Таблица 6-8. Ключи критерия limit

Ключ	`--limit`
Пример	iptables -A INPUT -m limit —limit 3/hour
Описание	Устанавливается средняя скорость «освобождения емкости» за единицу времени. В качестве аргумента указывается число пакетов и время. Допустимыми считаются следующие единицы измерения времени: `/second /minute /hour /day`. По умолчанию принято значение 3 пакета в час, или `3/hour`. Использование флага инверсии условия `!` в данном критерии недопустимо.
Ключ	`--limit-burst`
Пример	iptables -A INPUT -m limit —limit-burst 5
Описание	Устанавливает максимальное значение числа `burst limit` для критерия `limit`. Это число увеличивается на единицу если получен пакет, подпадающий под действие данного правила, и при этом средняя скорость (задаваемая ключом `--limit`) поступления пакетов уже достигнута. Так происходит до тех пор, пока число `burst limit` не достигнет максимального значения, устанавливаемого ключом `--limit-burst`. После этого правило начинает пропускать пакеты со скоростью, задаваемой ключом `--limit`. Значение по-умолчанию принимается равным 5. Для демонстрации принципов работы данного критерия я написал сценарий limit-match.txt С помощью этого сценария вы увидите как работает критерий `limit`, просто посылая `ping`-пакеты с различными временнЫми интервалами.

6.4.3.2. Критерий MAC

MAC (Ethernet Media Access Control) критерий используется для проверки исходного MAC-адреса пакета. Расширение -m mac, на сегодняшний день, предоставляет единственный критерий, но возможно в будущем он будет расширен и станет более полезен.

Модуль расширения должен подгружаться явно ключом -m mac. Упоминаю я об этом потому, что многие, забыв указать этот ключ, удивляются, почему не работает этот критерий.

Таблица 6-9. Ключи критерия MAC

Ключ	`--mac-source`
Пример	iptables -A INPUT -m mac —mac-source 00:00:00:00:00:01
Описание	MAC адрес сетевого узла, передавшего пакет. MAC адрес должен указываться в форме `XX:XX:XX:XX:XX:XX`. Как и ранее, символ `!` используется для инверсии критерия, например `--mac-source ! 00:00:00:00:00:01`, что означает — «пакет с любого узла, кроме узла, который имеет MAC адрес `00:00:00:00:00:01`» . Этот критерий имеет смысл только в цепочках `PREROUTING, FORWARD` и `INPUT` и нигде более.

6.4.3.3. Критерий Mark

Критерий mark предоставляет возможность «пометить» пакеты специальным образом. Mark — специальное поле, которое существует только в области памяти ядра и связано с конкретным пакетом. Может использоваться в самых разнообразных целях, например, ограничение трафика и фильтрация. На сегодняшний день существует единственная возможность установки метки на пакет в Linux — это использование действия MARK. Поле mark представляет собой беззнаковое целое число в диапазоне от 0 до 4294967296 для 32-битных систем.

Таблица 6-10. Ключи критерия Mark

Ключ	`--mark`
Пример	iptables -t mangle -A INPUT -m mark —mark 1
Описание	Критерий производит проверку пакетов, которые были предварительно «помечены». Метки устанавливаются действием `MARK`, которое мы будем рассматривать ниже. Все пакеты, проходящие через `netfilter` имеют специальное поле `mark`. Запомните, что нет никакой возможности передать состояние этого поля вместе с пакетом в сеть. Поле `mark` является целым беззнаковым, таким образом можно создать не более 4294967296 различных меток. Допускается использовать маску с меткам. В данном случае критерий будет выглядеть подобным образом: `--mark 1/1`. Если указывается маска, то выполняется логическое `AND` метки и маски.

6.4.3.4. Критерий Multiport

Расширение multiport позволяет указывать в тексте правила несколько портов и диапазонов портов.

Вы не сможете использовать стандартную проверку портов и расширение -m multiport (например --sport 1024:63353 -m multiport --dport 21,23,80) одновременно. Подобные правила будут просто отвергаться iptables.

Таблица 6-11. Ключи критерия Multiport

Ключ	`--source-port`
Пример	iptables -A INPUT -p tcp -m multiport —source-port 22,53,80,110
Описание	Служит для указания списка исходящих портов. С помощью данного критерия можно указать до 15 различных портов. Названия портов в списке должны отделяться друг от друга запятыми, пробелы в списке не допустимы. Данное расширение может использоваться только совместно с критериями `-p tcp` или `-p udp`. Главным образом используется как расширенная версия обычного критерия `--source-port`.
Ключ	`--destination-port`
Пример	iptables -A INPUT -p tcp -m multiport —destination-port 22,53,80,110
Описание	Служит для указания списка входных портов. Формат задания аргументов полностью аналогичен `-m multiport --source-port`.
Ключ	`--port`
Пример	iptables -A INPUT -p tcp -m multiport —port 22,53,80,110
Описание	Данный критерий проверяет как исходящий так и входящий порт пакета. Формат аргументов аналогичен критерию `--source-port` и `--destination-port`. Обратите внимание на то что данный критерий проверяет порты обеих направлений, т.е. если вы пишете `-m multiport --port 80`, то под данный критерий подпадают пакеты, идущие с порта 80 на порт 80.

6.4.3.5. Критерий Owner

Расширение owner предназначено для проверки «владельца» пакета. Изначально данное расширение было написано как пример демонстрации возможностей iptables. Допускается использовать этот критерий только в цепочке OUTPUT. Такое ограничение наложено потому, что на сегодняшний день нет реального механизма передачи информации о «владельце» по сети. Справедливости ради следует отметить, что для некоторых пакетов невозможно определить «владельца» в этой цепочке. К такого рода пакетам относятся различные ICMP responses. Поэтому не следует применять этот критерий к ICMP responses пакетам.

Таблица 6-12. Ключи критерия Owner

Ключ	`--uid-owner`
Пример	iptables -A OUTPUT -m owner —uid-owner 500
Описание	Производится проверка «владельца» по `User ID (UID)`. Подобного рода проверка может использоваться, к примеру, для блокировки выхода в Интернет отдельных пользователей.
Ключ	`--gid-owner`
Пример	iptables -A OUTPUT -m owner —gid-owner 0
Описание	Производится проверка «владельца» пакета по `Group ID (GID)`.
Ключ	`--pid-owner`
Пример	iptables -A OUTPUT -m owner —pid-owner 78
Описание	Производится проверка «владельца» пакета по `Process ID (PID)`. Этот критерий достаточно сложен в использовании, например, если мы хотим позволить передачу пакетов на HTTP порт только от заданного демона, то нам потребуется написать небольшой сценарий, который получает `PID` процесса (хотя бы через ps) и затем подставляет найденный `PID` в правила. Пример использования критерия можно найти в pid-owner.txt.
Ключ	`--sid-owner`
Пример	iptables -A OUTPUT -m owner —sid-owner 100
Описание	Производится проверка `Session ID` пакета. Значение SID наследуются дочерними процессами от «родителя», так, например, все процессы HTTPD имеют один и тот же SID (примером таких процессов могут служить HTTPD Apache и Roxen). Пример использования этого критерия можно найти в sid-owner.txt. Этот сценарий можно запускать по времени для проверки наличия процесса HTTPD, и в случае отсутствия — перезапустить «упавший» процесс, после чего сбросить содержимое цепочки `OUTPUT` и ввести ее снова.

6.4.3.6. Критерий State

Критерий state используется совместно с кодом трассировки соединений и позволяет нам получать информацию о признаке состояния соединения, что позволяет судить о состоянии соединения, причем даже для таких протоколов как ICMP и UDP. Данное расширение необходимо загружать явно, с помощью ключа -m state. Более подробно механизм определения состояния соединения обсуждается в разделе Механизм определения состояний .

Таблица 6-13. Ключи критерия State

Ключ	—state
Пример	iptables -A INPUT -m state —state RELATED,ESTABLISHED
Описание	Проверяется признак состояния соединения (`state`) На сегодняшний день можно указывать 4 состояния: `INVALID, ESTABLISHED, NEW` и `RELATED`. `INVALID` подразумевает, что пакет связан с неизвестным потоком или соединением и, возможно содержит ошибку в данных или в заголовке. Состояние `ESTABLISHED` указывает на то, что пакет принадлежит уже установленному соединению через которое пакеты идут в обеих направлениях. Признак `NEW` подразумевает, что пакет открывает новое соединение или пакет принадлежит однонаправленному потоку. И наконец, признак `RELATED` указывает на то что пакет принадлежит уже существующему соединению, но при этом он открывает новое соединение Примером тому может служить передача данных по `FTP`, или выдача сообщения `ICMP` об ошибке, которое связано с существующим `TCP` или `UDP` соединением. Замечу, что признак `NEW` это не то же самое, что установленный бит `SYN` в пакетах `TCP`, посредством которых открывается новое соединение, и, подобного рода пакеты, могут быть потенциально опасны в случае, когда для защиты сети вы используете один сетевой экран. Более подробно эта проблема рассматривается ниже в главе Механизм определения состояний.

6.4.3.7. Критерий TOS

Критерий TOS предназначен для проведения проверки битов поля TOS. TOS - Type Of Service — представляет собой 8-ми битовое, поле в заголовке IP-пакета. Модуль должен загружаться явно, ключом -m tos.

От переводчика: Далее приводится описание поля TOS, взятое не из оригинала, поскольку оригинальное описание я нахожу несколько туманным.

Данное поле служит для нужд маршрутизации пакета. Установка любого бита может привести к тому, что пакет будет обработан маршрутизатором не так как пакет со сброшенными битами TOS. Каждый бит поля TOS имеет свое значение. В пакете может быть установлен только один из битов этого поля, поэтому комбинации не допустимы. Каждый бит определяет тип сетевой службы:

Минимальная задержка Используется в ситуациях, когда время передачи пакета должно быть минимальным, т.е., если есть возможность, то маршрутизатор для такого пакета будет выбирать более скоростной канал. Например, если есть выбор между оптоволоконной линией и спутниковым каналом, то предпочтение будет отдано более скоростному оптоволокну.

Максимальная пропускная способность Указывает, что пакет должен быть переправлен через канал с максимальной пропускной способностью. Например спутниковые каналы, обладая большей задержкой имеют высокую пропускную способность.

Максимальная надежность Выбирается максимально надежный маршрут во избежание необходимости повторной передачи пакета. Примером могут служить PPP и SLIP соединения, которые по своей надежности уступают, к примеру, сетям X.25, поэтому, сетевой провайдер может предусмотреть специальный маршрут с повышенной надежностью.

Минимальные затраты Применяется в случаях, когда важно минимизировать затраты (в смысле деньги) на передачу данных. Например, при передаче через океан (на другой континент) аренда спутникового канала может оказаться дешевле, чем аренда оптоволоконного кабеля. Установка данного бита вполне может привести к тому, что пакет пойдет по более «дешевому» маршруту.

Обычный сервис В данной ситуации все биты поля TOS сброшены. Маршрутизация такого пакета полностью отдается на усмотрение провайдера.

Таблица 6-14. Ключи критерия TOS

Ключ	`--tos`
Пример	iptables -A INPUT -p tcp -m tos —tos 0x16
Описание	Данный критерий предназначен для проверки установленных битов `TOS`, которые описывались выше. Как правило поле используется для нужд маршрутизации, но вполне может быть использовано с целью «маркировки» пакетов для использования с `iproute2` и дополнительной маршрутизации в linux. В качестве аргумента критерию может быть передано десятичное или шестнадцатиричное число, или мнемоническое описание бита, мнемоники и их числовое значение вы можете получить выполнив команду iptables -m tos -h. Ниже приводятся мнемоники и их значения. `Minimize-Delay 16 (0x10)` (Минимальная задержка), `Maximize-Throughput 8 (0x08)` (Максимальная пропускная способность), `Maximize-Reliability 4 (0x04)` (Максимальная надежность), `Minimize-Cost 2 (0x02)` (Минимальные затраты), `Normal-Service 0 (0x00)` (Обычный сервис)

6.4.3.8. Критерий TTL

TTL (Time To Live) является числовым полем в IP заголовке. При прохождении очередного маршрутизатора, это число уменьшается на 1. Если число становится равным нулю, то отправителю пакета будет передано ICMP сообщение типа 11 с кодом 0 (TTL equals 0 during transit) или с кодом 1 (TTL equals 0 during reassembly) . Для использования этого критерия необходимо явно загружать модуль ключом -m ttl.

От переводчика: Опять обнаружилось некоторое несоответствие оригинального текста с действительностью, по крайней мере для iptables 1.2.6a, о которой собственно и идет речь, существует три различных критерия проверки поля TTL, это -m ttl --ttl-eq число, -m ttl --ttl-lt число и -m ttl --ttl-gt число. Назначение этих критериев понятно уже из их синтаксиса. Тем не менее, я все таки приведу перевод оригинала:

Таблица 6-15. Ключи критерия TTL

Ключ	—ttl
Пример	iptables -A OUTPUT -m ttl —ttl 60
Описание	Производит проверку поля `TTL` на равенство заданному значению. Данный критерий может быть использован при наладке локальной сети, например: для случаев, когда какая либо машина локальной сети не может подключиться к серверу в Интернете, или для поиска «троянов» и пр. Вобщем, области применения этого поля ограничиваются только вашей фантазией. Еще один пример: использование этого критерия может быть направлено на поиск машин с некачественной реализацией стека `TCP/IP` или с ошибками в конфигурации ОС.

6.4.4. Критерий «мусора» (Unclean match)

Критерий unclean не имеет дополнительных ключей и для его использования достаточно явно загрузить модуль. Будьте осторожны, данный модуль находится еще на стадии разработки и поэтому в некоторых ситуациях может работать некорректно. Данная проверка производится для вычленения пакетов, которые имеют расхождения с принятыми стандартами, это могут быть пакеты с поврежденным заголовком или с неверной контрольной суммой и пр., однако использование этой проверки может привести к разрыву и вполне корректного соединения.

6.5. Действия и переходы¶

Действия и переходы сообщают правилу, что необходимо выполнить, если пакет соотвествует заданному критерию. Чаще всего употребляются действия ACCEPT и DROP. Однако, давайте кратко рассмотрим понятие переходов.

Описание переходов в правилах выглядит точно так же как и описание действий, т.е. ставится ключ -j и указывается название цепочки правил, на которую выполняется переход. На переходы накладывается ряд ограничений, первое — цепочка, на которую выполняется переход, должна находиться в той же таблице, что и цепочка, из которой этот переход выполняется, второе — цепочка , являющаяся целью перехода должна быть создана до того как на нее будут выполняться переходы. Например, создадим цепочку tcp_packets в таблице filter с помощью команды

iptables -N tcp_packets

Теперь мы можем выполнять переходы на эту цепочку подобно:

iptables -A INPUT -p tcp -j tcp_packets

Т.е. встретив пакет протокола tcp, iptables произведет переход на цепочку tcp_packets и продолжит движение пакета по этой цепочке. Если пакет достиг конца цепочки то он будет возвращен в вызывающую цепочку (в нашем случае это цепочка INPUT) и движение пакета продолжится с правила, следующего за правилом, вызвавшем переход. Если к пакету во вложенной цепочке будет применено действие ACCEPT, то автоматически пакет будет считаться принятым и в вызывающей цепочке и уже не будет продолжать движение по вызывающим цепочкам. Однако пакет пойдет по другим цепочкам в других таблицах. Дополнительную информацию о порядке прохождения цепочек и таблиц вы сможете получить в главе Порядок прохождения таблиц и цепочек.

Действие — это предопределенная команда, описывающая действие, которое необходимо выполнить, если пакет совпал с заданным критерием. Например, можно применить действие DROP или ACCEPT к пакету, в зависимости от наших нужд. Существует и ряд других действий, которые описываются ниже в этом разделе. В результате выполнения одних действий, пакет прекращает свое прохождение по цепочке, например DROP и ACCEPT, в результате других, после выполнения неких операций, продолжает проверку, например, LOG, в результате работы третьих даже видоизменяется, например DNAT и SNAT, TTL и TOS, но так же продолжает продвижение по цепочке.

6.5.1. Действие ACCEPT

Данная операция не имеет дополнительных ключей. Если над пакетом выполняется действие ACCEPT, то пакет прекращает движение по цепочке (и всем вызвавшим цепочкам, если текущая цепочка была вложенной) и считается ПРИНЯТЫМ (то бишь пропускается), тем не менее, пакет продолжит движение по цепочкам в других таблицах и может быть отвергнут там. Действие задается с помощью ключа -j ACCEPT.

6.5.2. Действие DNAT

DNAT (Destination Network Address Translation) используется для преобразования адреса места назначения в IP заголовке пакета. Если пакет подпадает под критерий правила, выполняющего DNAT, то этот пакет, и все последующие пакеты из этого же потока, будут подвергнуты преобразованию адреса назначения и переданы на требуемое устройство, хост или сеть. Данное действие может, к примеру, успешно использоваться для предоставления доступа к вашему web-серверу, находящемуся в локальной сети, и не имеющему реального IP адреса. Для этого вы строите правило, которое перехватывает пакеты, идущие на HTTP порт брандмауэра и выполняя DNAT передаете их на локальный адрес web-сервера. Для этого действия так же можно указать диапазон адресов, тогда выбор адреса назначения для каждого нового потока будет производиться случайнам образом.

Действие DNAT может выполняться только в цепочках PREROUTING и OUTPUT таблицы nat, и во вложенных под-цепочках. Важно запомнить, что вложенные подцепочки, реализующие DNAT не должны вызываться из других цепочек, кроме PREROUTING и OUTPUT.

Таблица 6-16. Действие DNAT

Ключ	`--to-destination`
Пример	iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 —dport 80 -j DNAT —to-destination 192.168.1.1-192.168.1.10
Описание	Ключ `--to-destination` указывает, какой IP адрес должен быть подставлен в качестве адреса места назначения. В выше приведенном примере во всех пакетах, пришедших на адрес 15.45.23.67, адрес назначения будет изменен на один из диапазона от 192.168.1.1 до 192.168.1.10. Как уже указывалось выше, все пакеты из одного потока будут направляться на один и тот же адрес, а для каждого нового потока будет выбираться один из адресов в указанном диапазоне случайным образом. Можно также определить единственный IP адрес. Можно дополнительно указать порт или диапазон портов, на который (которые) будет перенаправлен траффик. Для этого после ip адреса через двоеточие укажите порт, например `--to-destination 192.168.1.1:80`, а указание диапазона портов выглядит так: `--to-destination 192.168.1.1:80-100`. Как вы можете видеть, синтаксис действий `DNAT` и `SNAT` во многом схож. Не забывайте, что указание портов допускается только при работе с протоколом `TCP` или `UDP`, при наличии опции `--protocol` в критерии.

Действие DNAT достаточно сложно в использовании и требует дополнительного пояснения. Рассмотрим простой пример. У нас есть WEB сервер и мы хотим разрешить доступ к нему из Интернет. Мы имеем только один реальный IP адрес, а WEB-сервер расположен в локальной сети. Реальный IP адрес $INET_IP назначен брандмауэру, HTTP сервер имеет локальный адрес $HTTP_IP и, наконец брандмауэр имеет локальный адрес $LAN_IP. Для начала добавим простое правило в цепочку PREROUTING таблицы nat:

iptables -t nat -A PREROUTING —dst $INET_IP -p tcp —dport 80 -j DNAT —to-destination $HTTP_IP

В соответствии с этим правилом, все пакеты, поступающие на 80-й порт адреса $INET_IP перенаправляются на наш внутренний WEB-сервер. Если теперь обратиться к WEB-серверу из Интернет, то все будет работать прекрасно. Но что же произойдет, если попробовать соединиться с ним из локальной сети? Соединение просто не установится. Давайте посмотрим как маршрутизируются пакеты, идущие из Интернет на наш WEB-сервер. Для простоты изложения примем адрес клиента в Интернет равным $EXT_BOX.

Пакет покидает клиентский узел с адресом $EXT_BOX и направляется на $INET_IP
Пакет приходит на наш брандмауэр.
Брандмауэр, в соответствии с вышеприведенным правилом, подменяет адрес назначения и передает его дальше, в другие цепочки.
Пакет передается на $HTTP_IP.
Пакет поступает на HTTP сервер и сервер передает ответ через брандмауэр, если в таблице маршрутизации он обозначен как шлюз для $EXT_BOX. Как правило, он назначается шлюзом по-умолчанию для HTTP сервера.
Брандмауэр производит обратную подстановку адреса в пакете, теперь все выглядит так, как будто бы пакет был сформирован на брандмауэре.
Пакет передается клиенту $EXT_BOX.

А теперь посмотрим, что произойдет, если запрос посылается с узла, расположенного в той же локальной сети. Для простоты изложения примем адрес клиента в локальной сети равным $LAN_BOX.

Пакет покидает $LAN_BOX.
Поступает на брандмауэр.
Производится подстановка адреса назначения, однако адрес отправителя не подменяется, т.е. исходный адрес остается в пакете без изменения.
Пакет покидает брандмауэр и отправляется на HTTP сервер.
HTTP сервер, готовясь к отправке ответа, обнаруживает, что клиент находится в локальной сети (поскольку пакет запроса содержал оригинальный IP адрес, который теперь превратился в адрес назначения) и поэтому отправляет пакет непосредственно на $LAN_BOX.
Пакет поступает на $LAN_BOX. Клиент «путается», поскольку ответ пришел не с того узла, на который отправлялся запрос. Поэтому клиент «сбрасывает» пакет ответа и продолжает ждать «настоящий» ответ.

Проблема решается довольно просто с помощью SNAT. Ниже приводится правило, которое выполняет эту функцию. Это правило вынуждает HTTP сервер передавать ответы на наш брандмауэр, которые затем будут переданы клиенту.

iptables -t nat -A POSTROUTING -p tcp —dst $HTTP_IP —dport 80 -j SNAT
—to-source $LAN_IP

Запомните, цепочка POSTROUTING обрабатывается самой последней и к этому моменту пакет уже прошел процедуру преобразования DNAT, поэтому критерий строится на базе адреса назначения $HTTP_IP.

Если вы думаете, что на этом можно остановиться, то вы ошибаетесь! Представим себе ситуацию, когда в качестве клиента выступает сам брандмауэр. Тогда, к сожалению, пакеты будут передаваться на локальный порт с номером 80 самого брандмауэра, а не на $HTTP_IP. Чтобы разрешить и эту проблему, добавим правило:

iptables -t nat -A OUTPUT —dst $INET_IP -p tcp —dport 80 -j DNAT
—to-destination $HTTP_IP

Теперь никаких проблем, с доступом к нашему WEB-серверу, уже не должно возникать.

Каждый должен понять, что эти правила предназначены только лишь для корректной обработки адресации пакетов. В дополнение к этим правилам вам может потребоваться написать дополнительные правила для цепочки FORWARD таблицы filter. Не забудьте при этом, что пакеты уже прошли цепочку PREROUTING и поэтому их адреса назначения уже изменены действием DNAT.

6.5.3. Действие DROP

Данное действие просто «сбрасывает» пакет и iptables «забывает» о его существовании. «Сброшенные» пакеты прекращают свое движение полностью, т.е. они не передаются в другие таблицы, как это происходит в случае с действием ACCEPT. Следует помнить, что данное действие может иметь негативные последствия, поскольку может оставлять незакрытые «мертвые» сокеты как на стороне сервера, так и на стороне клиента, наилучшим способом защиты будет использование действия REJECT особенно при защите от сканирования портов.

6.5.4. Действие LOG

LOG — действие, которое служит для журналирования отдельных пакетов и событий. В журнал могут заноситься заголовки IP пакетов и другая интересующая вас информация. Информация из журнала может быть затем прочитана с помощью dmesg или syslogd либо с помощью других программ. Превосходное средство для отладки ваших правил. Неплохо было бы на период отладки правил вместо действия DROP использовать действие LOG, чтобы до конца убедиться, что ваш брандмауэр работает безупречно. Обратите ваше внимание так же на действие ULOG, которое наверняка заинтересует вас своими возможностями, поскольку позволяет выполнять запись журналируемой информации не в системный журнал, а в базу данных MySQL и т.п..

Обратите внимание — если у вас имеются проблемы с записью в системный журнал, то это проблемы не iptables или netfilter, а syslogd. За информацией по конфигурированию @syslogd обращайтесь к man syslog.conf.

Действие LOG имеет пять ключей, которые перечислены ниже.

Таблица 6-17. Ключи действия LOG

Ключ
Пример	iptables -A FORWARD -p tcp -j LOG —log-level debug
Описание	Используется для задания уровня журналирования (`log level`). Полный список уровней вы найдете в руководстве (man) по `syslog.conf`. Обычно, можно задать следующие уровни: `debug, info, notice, warning, warn, err, error, crit, alert, emerg` и `panic`. Ключевое слово error означает то же самое, что и `err, warn - warning` и `panic - emerg`. Важно: в последних трех парах слов не следует использовать `error, warn` и `panic`. Приоритет определяет различия в том как будут заноситься сообщения в журнал. Все сообщения заносятся в журнал средствами ядра. Если вы установите строку `kern.=info /var/log/iptables` в файле `syslog.conf`, то все ваши сообщения из `iptables`, использующие уровень `info`, будут заноситься в файл `/var/log/iptables`. Однако, в этот файл попадут и другие сообщения, поступающие из других подсистем, которые используют уровень info. За дополнительной информацией по @syslog @и @syslog.conf @я рекомендую обращаться к manpages и HOWTO.
Ключ	`--log-prefix`
Пример	iptables -A INPUT -p tcp -j LOG —log-prefix «INPUT packets»
Описание	Ключ задает текст (префикс), которым будут предваряться все сообщения iptables. Сообщения со специфичным префиксом затем легко можно найти, к примеру, с помощью grep. Префикс может содержать до 29 символов, включая и пробелы.
Ключ	`--log-tcp-sequence`
Пример	iptables -A INPUT -p tcp -j LOG —log-tcp-sequence
Описание	Этот ключ позволяет заносить в журнал номер `TCP Sequence` пакета. Номер `TCP Sequence` идентифицирует каждый пакет в потоке и определяет порядок «сборки» потока. Этот ключ потенциально опасен для безопасности системы, если системный журнал разрешает доступ «НА ЧТЕНИЕ» всем пользователям. Как и любой другой журнал, содержащий сообщения от iptables.
Ключ	`--log-tcp-options`
Пример	iptables -A FORWARD -p tcp -j LOG —log-tcp-options
Описание	Этот ключ позволяет заносить в системный журнал различные сведения из заголовка TCP пакета. Такая возможность может быть полезна при отладке. Этот ключ не имеет дополнительных параметров, как и большинство ключей действия LOG.
Ключ	`--log-ip-options`
Пример	iptables -A FORWARD -p tcp -j LOG —log-ip-options
Описание	Этот ключ позволяет заносить в системный журнал различные сведения из заголовка IP пакета. Во многом схож с ключом `--log-tcp-options`, но работает только с IP заголовком.

6.5.5. Действие MARK

Используется для установки меток для определенных пакетов. Это действие может выполняться только в пределах таблицы mangle. Установка меток обычно используется для нужд маршрутизации пакетов по различным маршрутам, для ограничения трафика и т.п.. За дополнительной информацией вы можете обратиться к Linux Advanced Routing and Traffic Control HOW-TO. Не забывайте, что «метка» пакета существует только в период времени пока пакет не покинул брандмауэр, т.е. метка не передается по сети. Если необходимо как-то пометить пакеты, чтобы использовать маркировку на другой машине, то можете попробовать манипулировать битами поля TOS.

Таблица 6-18. Ключи действия MARK

Ключ	`--set-mark`
Пример	iptables -t mangle -A PREROUTING -p tcp —dport 22 -j MARK —set-mark 2
Описание	Ключ `--set-mark` устанавливает метку на пакет. После ключа `--set-mark` должно следовать целое беззнаковое число.

6.5.6. Действие MASQUERADE

Маскарадинг (MASQUERADE) в основе своей представляет то же самое, что и SNAT только не имеет ключа --to-source. Причиной тому то, что маскарадинг может работать, например, с dialup подключением или DHCP, т.е. в тех случаях, когда IP адрес присваивается устройству динамически. Если у вас имеется динамическое подключение, то нужно использовать маскарадинг, если же у вас статическое IP подключение, то бесспорно лучшим выходом будет использование действия SNAT.

Маскарадинг подразумевает получение IP адреса от заданного сетевого интерфейса, вместо прямого его указания, как это делается с помощью ключа --to-source в действии SNAT. Действие MASQUERADE имеет хорошее свойство — «забывать» соединения при остановке сетевого интерфейса. В случае же SNAT, в этой ситуации, в таблице трассировщика остаются данные о потерянных соединениях, и эти данные могут сохраняться до суток, поглощая ценную память. Эффект «забывчивости» связан с тем, что при остановке сетевого интерфейса с динамическим IP адресом, есть вероятность на следующем запуске получить другой IP адрес, но в этом случае любые соединения все равно будут потеряны, и было бы глупо хранить трассировочную информацию.

Как вы уже поняли, действие MASQUERADE может быть использовано вместо SNAT, даже если вы имеете постоянный IP адрес, однако, невзирая на положительные черты, маскарадинг не следует считать предпочтительным в этом случае, поскольку он дает большую нагрузку на систему.

Действие MASQUERADE допускается указывать только в цепочке POSTROUTING таблицы nat, так же как и действие SNAT. MASQUERADE имеет ключ, описываемый ниже, использование которого необязательно.

Таблица 6-19. Действие MASQUERADE

Ключ	`--to-ports`
Пример	iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE —to-ports 1024-31000
Описание	Ключ `--to-ports` используется для указания порта источника или диапазона портов исходящего пакета. Можно указать один порт, например: `--to-ports 1025`, или диапазон портов как здесь: `--to-ports 1024-3000`. Этот ключ можно использовать только в правилах, где критерий содержит явное указание на протокол TCP или UDP с помощью ключа `--protocol`.

6.5.7. Действие MIRROR

Действие MIRROR может использоваться вами только для экспериментов и в демонстрационных целях, поскольку это действие может привести к «зацикливанию» пакета и в результате к «Отказу от обслуживания». В результате действия MIRROR в пакете, поля source и destination меняются местами (invert the source and destination fields) и пакет отправляется в сеть. Использование этой команды может иметь весьма забавный результат, наверное, со стороны довольно потешно наблюдать, как какой нибудь кульхацкер пытается «взломать» свой собственный компьютер!

Данное действие допускается использовать только в цепочках INPUT, FORWARD и PREROUTING, и в цепочках, вызываемых из этих трех. Пакеты, отправляемые в сеть действием MIRROR больше не подвергаются фильтрации, трассировке или NAT, избегая тем самым «зацикливания» и других неприятностей. Однако это не означает, что проблем с этим действием нет. Давайте, к примеру, представим, что на хосте, использующем действие MIRROR фабрикуется пакет, с TTL равным 255, на этот же самый хост и пакет подпадает под критерий «зеркалирующего» правила. Пакет «отражается» на этот же хост, а поскольку между «приемником» и «передатчиком» только 1 хоп (hop) то пакет будет прыгать туда и обратно 255 раз. Неплохо для крякера, ведь, при величине пакета 1500 байт, мы потеряем до 380 Кбайт трафика!

6.5.8. Действие QUEUE

Действие QUEUE ставит пакет в очередь на обработку пользовательскому процессу. Оно может быть использовано для нужд учета, проксирования или дополнительной фильтрации пакетов.

От переводчика: Далее автор пространно рассуждает о том, что обсуждение данной темы далеко выходит за рамки документа и пр., поэтому, не мудрствуя лукаво, приведу здесь выдержку из http://antonio.mccinet.ru/protection/iptables_howto.html в переводе Евгения Данильченко aka virii5, eugene@kriljon.ru:

«…Для того чтобы эта цель была полезна, необходимы еще два компонента:
«queue handler» — обработчик очереди, который выполняет работу по передаче пакетов между ядром и пользовательским приложением; и
пользовательское приложение которое будет получать, возможно обрабатывать, и решать судьбу пакетов.
Стандартный обработчик очереди для IPv4 — модуль ip-queue, который распространяется с ядром и помечен как экспериментальный. Ниже дан пример, как можно использовать iptables для передачи пакетов в пользовательское приложение:
# modprobe iptable_filter
# modprobe ip_queue
# iptables -A OUTPUT -p icmp -j QUEUE
С этим правилом, созданные локально пакеты ICMP типа (такие, что создаются скажем при помощи команды ping) попадают в модуль ip_queue, который затем пытается передать их в пользовательское приложение. Если ни одно из таких приложений не найдено, пакеты сбрасываются. Чтобы написать пользовательскую программу обработки пакетов, используйте libipq API. Оно распространяется с пакетом iptables. Примеры можно найти в testsuite tools (например redirect.c) на CVS. Статус ip_queue можно проверить с помощью: /proc/net/ip_queue Максимальную длинну очереди (то есть, число пакетов передаваемых в пользовательское приложение без подтверждения обработки) можно контролировать с помощью: /proc/sys/net/ipv4/ip_queue_maxlen По умолчанию — максимальная длинна очереди равна 1024. Как только этот предел достигается, новые пакеты будут сбрасываться, пока очередь не снизиться ниже данного предела. Хорошие протоколы, такие как TCP интерпретируют сброшенные пакеты как перегруженность канала передачи, и успешно с этим справляются (насколько я помню, пакет будет просто переслан заново удаленной стороной, прим. перевод.). Однако, может потребоваться некоторого рода эксперементирование, чтобы определить оптимальную длину очереди в каждом конкретном случае, если по умолчанию очередь слишком мала…»

6.5.9. Действие REDIRECT

Выполняет перенаправление пакетов и потоков на другой порт той же самой машины. К примеру, можно пакеты, поступающие на HTTP порт перенаправить на порт HTTP proxy. Действие REDIRECT очень удобно для выполнения «прозрачного» проксирования (transparent proxying), когда машины в локальной сети даже не подозревают о существовании прокси.

REDIRECT может использоваться только в цепочках PREROUTING и OUTPUT таблицы nat. И конечно же это действие можно выполнять в подцепочках, вызываемых и вышеуказанных. Для действия REDIRECT предусмотрен только один ключ.

Таблица 6-20. Действие REDIRECT

Ключ	`--to-ports`
Пример	iptables -t nat -A PREROUTING -p tcp —dport 80 -j REDIRECT —to-ports 8080
Описание	Ключ `--to-ports` определяет порт или диапазон портов назначения. Без указания ключа `--to-ports`, перенаправления не происходит, т.е. пакет идет на тот порт, куда и был назначен. В примере, приведенном выше, `--to-ports 8080` указан один порт назначения. Если нужно указать диапазон портов, то мы должны написать нечто подобное `--to-ports 8080-8090`. Этот ключ можно использовать только в правилах, где критерий содержит явное указание на протокол TCP или UDP с помощью ключа `--protocol`.

6.5.10. Действие REJECT

REJECT используется, как правило, в тех же самых ситуациях, что и DROP, но в отличие от DROP, команда REJECT выдает сообщение об ошибке на хост, передавший пакет. Действие REJECT на сегодняшний день может использоваться только в цепочках INPUT, FORWARD и OUTPUT (и во вложенных в них цепочках). Пока существует только единственный ключ, управляющий поведением команды REJECT.

Таблица 6-21. Действие REJECT

Ключ	`--reject-with`
Пример	iptables -A FORWARD -p TCP —dport 22 -j REJECT —reject-with tcp-reset
Описание	Указывает, какое сообщение необходимо передать в ответ, если пакет совпал с заданным критерием. При применении действия REJECT к пакету, сначала на хост-отправитель будет отослан указанный ответ, а затем пакет будет «сброшен». Допускается использовать следующие типы ответов: `icmp-net-unreachable`, `icmp-host-unreachable`, `icmp-port-unreachable`, `icmp-proto-unreachable`, `icmp-net-prohibited` и `icmp-host-prohibited`. По-умолчанию передается сообщение `port-unreachable`. Все вышеуказанные типы ответов являются `ICMP error messages`. Дополнительную информацию по типам ICMP сообщений вы можете получить в приложении Типы ICMP. В заключение укажем еще один тип ответа — `tcp-reset`, который используется только для протокола TCP. Если указано значение `tcp-reset`, то действие `REJECT` передаст в ответ пакет `TCP RST`, пакеты `TCP RST` используются для закрытия TCP соединений. За дополнительной информацией обращайтесь к RFC 793 — Transmission Control Protocol. (Список типов `ICMP` ответов и их алиасов вы сможете получить введя команду iptables -j REJECT -h прим. перев.).

6.5.11. Действие RETURN

Действие RETURN прекращает движение пакета по текущей цепочке правил и производит возврат в вызывающую цепочку, если текущая цепочка была вложенной, или, если текущая цепочка лежит на самом верхнем уровне (например INPUT), то к пакету будет применена политика по-умолчанию. Обычно, в качестве политики по-умолчанию назначают действия ACCEPT или DROP .

Для примера, допустим, что пакет идет по цепочке INPUT и встречает правило, которое производит переход во вложенную цепочку — --jump EXAMPLE_CHAIN. Далее, в цепочке EXAMPLE_CHAIN пакет встречает правило, которое выполняет действие --jump RETURN. Тогда произойдет возврат пакета в цепочку INPUT. Другой пример, пусть пакет встречает правило, которое выполняет действие --jump RETURN в цепочке INPUT. Тогда к пакету будет применена политика по-умолчанию цепочки INPUT.

6.5.12. Действие SNAT

SNAT используется для преобразования сетевых адресов (Source Network Address Translation), т.е. изменение исходящего IP адреса в IP заголовке пакета. Например, это действие можно использовать для предоставления выхода в Интернет другим компьютерам из локальной сети, имея лишь один уникальный IP адрес. Для этого. необходимо включить пересылку пакетов (forwarding) в ядре и затем создать правила, которые будут транслировать исходящие IP адреса нашей локальной сети в реальный внешний адрес. В результате, внешний мир ничего не будет знать о нашей локальной сети, он будет считать, что запросы пришли с нашего брандмауэра.

SNAT допускается выполнять только в таблице nat, в цепочке POSTROUTING. Другими словами, только здесь допускается преобразование исходящих адресов. Если первый пакет в соединении подвергся преобразованию исходящего адреса, то все последующие пакеты, из этого же соединения, будут преобразованы автоматически и не пойдут через эту цепочку правил.

Таблица 6-22. Действие SNAT

Ключ	`--to-source`
Пример	iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT —to-source 194.236.50.155-194.236.50.160:1024-32000
Описание	Ключ `--to-source` используется для указания адреса, присваемового пакету. Все просто, вы указываете IP адрес, который будет подставлен в заголовок пакета в качестве исходящего. Если вы собираетесь перераспределять нагрузку между несколькими брандмауэрами, то можно указать диапазон адресов, где начальный и конечный адреса диапазона разделяются дефисом, например: 194.236.50.155-194.236.50.160. Тогда, конкретный IP адрес будет выбираться из диапазона случайным образом для каждого нового потока. Дополнительно можно указать диапазон портов, которые будут использоваться только для нужд SNAT. Все исходящие порты будут после этого перекартироваться в заданный диапазон. iptables старается, по-возможности, избегать перекартирования портов, однако не всегда это возможно, и тогда производится перекартирование . Если диапазон портов не задан, то исходные порты ниже 512 перекартируются в диапазоне 0-511, порты в диапазоне 512-1023 перекартируются в диапазоне 512-1023, и, наконец порты из диапазона 1024-65535 перекартируются в диапазоне 1024-65535. Что касается портов назначения, то они не подвергаются перекартированию.

6.5.13. Действие TOS

Команда TOS используется для установки битов в поле Type of Service IP заголовка. Поле TOS содержит 8 бит, которые используются для маршрутизации пакетов. Это один из нескольких полей, используемых iproute2. Так же важно помнить, что данное поле может обрабатываться различными маршрутизаторами с целью выбора маршрута движения пакета. Как уже указывалось выше, это поле, в отличие от MARK, сохраняет свое значение при движении по сети, а поэтому может использоваться вами для маршрутизации пакета. На сегодняшний день, большинство маршрутизаторов в Интернете никак не обрабатывают это поле, однако есть и такие, которые смотрят на него. Если вы используете это поле в своих нуждах, то подобные маршрутизаторы могут принять неверное решение при выборе маршрута, поэтому, лучше всего использовать это поле для своих нужд только в пределах вашей WAN или LAN.

Внимание!

Действие TOS воспринимает только предопределенные числовые значения и мнемоники, которые вы можете найти в linux/ip.h. Если вам действительно необходимо устанавливать произвольные значения в поле TOS, то можно воспользоваться «заплатой» FTOS с сайта Paksecured Linux Kernel patches, поддерживаемого Matthew G. Marsh. Однако, будьте крайне осторожны с этой «заплатой». Не следует использовать нестандартные значения TOS иначе как в особенных ситуациях.

Данное действие допускается выполнять только в пределах таблицы mangle.

В некоторых старых версиях iptables (1.2.2 и ниже) это действие реализовано с ошибкой (не исправляется контрольная сумма пакета), а это ведет к нарушению протокола обмена и в результате такие соединения обрываются.

Команда TOS имеет только один ключ, который описан ниже.

Таблица 6-23. Действие TOS

Ключ	`--set-tos`
Пример	iptables -t mangle -A PREROUTING -p TCP —dport 22 -j TOS —set-tos 0x10
Описание	Ключ `--set-tos` определяет числовое значение в десятичном или шестнадцатиричном виде. Поскольку поле TOS является 8-битным, то вы можете указать число в диапазоне от 0 до 255 (0x00 — 0xFF). Однако, большинство значений этого поля никак не используются. Вполне возможно, что в будущих реализациях TCP/IP числовые значения могут быть изменены, поэтому, во-избежание ошибок, лучше использовать мнемонические обозначения: `Minimize-Delay` (16 или 0x10), `Maximize-Throughput` (8 или 0x08), `Maximize-Reliability` (4 или 0x04), `Minimize-Cost` (2 или 0x02) или `Normal-Service` (0 или 0x00). По-умолчанию большинство пакетов имеют признак `Normal-Service`, или 0. Список мнемоник вы сможете получить, выполнив команду iptables -j TOS -h.

6.5.14. Действие TTL

Действие TTL используется для изменения содержимого поля Time To Live в IP заголовке. Один из вариантов применения этого действия — это устанавливать значение поля Time To Live ВО ВСЕХ исходящих пакетах в одно и то же значение. Для чего это?! Есть некоторые провайдеры, которые очень не любят, когда одним подключением пользуется несколько компьютеров, если мы начинаем устанавливать на все пакеты одно и то же значение TTL, то тем самым мы лишаем провайдера одного из критериев определения того, что подключение к Интернету разделяется несколькими компьютерами. Для примера можно привести число TTL = 64, которое является стандартным для ядра Linux.

За дополнительной информацией по установке значения по-умолчанию обращайтесь к ip-sysctl.txt, который вы найдете в приложении
Ссылки на другие ресурсы.

Действие TTL можно указывать только в таблице mangle и нигде больше. Для данного действия предусмотрено 3 ключа, описываемых ниже.

Таблица 6-24. Действие TTL
|Ключ | --ttl-set|
|Пример |iptables -t mangle -A PREROUTING -i eth0 -j TTL —ttl-set 64|
|Описание | Устанавливает поле TTL в заданное значение. Оптимальным считается значение около 64. Это не слишком много, но и не слишком мало. Не задавайте слишком большое значение, это может иметь неприятные последствия для вашей сети. Представьте себе, что пакет «зацикливается» между двумя неправильно сконфигурированными роутерами, тогда, при больших значениях TTL, есть риск «потерять» значительную долю пропускной способности канала.|
|Ключ | --ttl-dec|
|Пример |iptables -t mangle -A PREROUTING -i eth0 -j TTL —ttl-dec 1|
|Описание | Уменьшает значение поля TTL на заданное число. Например, пусть входящий пакет имеет значение TTL равное 53 и мы выполняем команду --ttl-dec 3, тогда пакет покинет наш хост с полем TTL равным 49. Не забывайте, что сетевой код автоматически уменьшит значение TTL на 1, поэтому, фактически мы получаем 53 — 3 — 1 = 49.|
|Ключ | --ttl-inc|
|Пример | iptables -t mangle -A PREROUTING -i eth0 -j TTL —ttl-inc 1|
|Описание |Увеличивает значение поля TTL на заданное число. Возьмем предыдущий пример, пусть к нам поступает пакет с TTL = 53, тогда, после выполнения команды --ttl-inc 4, на выходе с нашего хоста, пакет будет иметь TTL = 56, не забывайте об автоматическом уменьшении поля TTL сетевым кодом ядра, т.е. фактически мы получаем выражение 53 + 4 — 1 = 56. Увеличение поля TTL может использоваться для того, чтобы сделать наш брандмауэр менее «заметным» для трассировщиков (traceroutes). Программы трассировки любят за ценную информацию при поиске проблемных участков сети, и ненавидят за это же, поскольку эта информация может использоваться крякерами в неблаговидных целях. Пример использования вы можете найти в сценарии ttl-inc.txt.

6.5.15. Действие ULOG

Действие ULOG предоставляет возможность журналирования пакетов в пользовательское пространство. Оно заменяет традиционное действие LOG, базирующееся на системном журнале. При использовании этого действия, пакет, через сокеты netlink, передается специальному демону который может выполнять очень детальное журналирование в различных форматах (обычный текстовый файл, база данных MySQL и пр.) и к тому же поддерживает возможность добавления надстроек (плагинов) для формирования различных выходных форматов и обработки сетевых протоколов. Пользовательскую часть ULOGD вы можете получить на домашней странице ULOGD project page.

Таблица 6-25. Действие ULOG

Ключ	`--ulog-nlgroup`
Пример	iptables -A INPUT -p TCP —dport 22 -j ULOG —ulog-nlgroup 2
Описание	Ключ `--ulog-nlgroup` сообщает `ULOG` в какую группу netlink должен быть передан пакет. Всего существует 32 группы (от 1 до 32). Если вы желаете передать пакет в 5-ю группу, то можно просто указать `--ulog-nlgroup 5`. По-умолчанию используется 1-я группа.
Ключ	`--ulog-prefix`
Пример	iptables -A INPUT -p TCP —dport 22 -j ULOG —ulog-prefix «SSH connection attempt: «
Описание	Ключ `--ulog-prefix` имеет тот же смысл, что и аналогичная опция в действии `LOG`. Длина строки префикса не должна превышать 32 символа
Ключ	`--ulog-cprange`
Пример	iptables -A INPUT -p TCP —dport 22 -j ULOG —ulog-cprange 100
Описание	Ключ `--ulog-cprange` определяет, какую долю пакета, в байтах, надо передавать демону `ULOG`. Если указать число 100, как показано в примере, то демону будет передано только 100 байт из пакета, это означает, что демону будет передан заголовок пакета и некоторая часть области данных пакета. Если указать 0, то будет передан весь пакет, независимо от его размера. Значение по-умолчанию равно 0.
Ключ	`--ulog-qthreshold`
Пример	iptables -A INPUT -p TCP —dport 22 -j ULOG —ulog-qthreshold 10
Описание	Ключ `--ulog-qthreshold` устанавливает величину буфера в области ядра. Например, если задать величину буфера равной 10, как в примере, то ядро будет накапливать журналируемые пакеты во внутреннем буфере и передавать в пользовательское пространство группами по 10 пакетов. По-умолчанию размер буфера равен 1 из-за сохранения обратной совместимости с ранними версиями ulogd, которые не могли принимать группы пакетов.

Глава 7. Файл rc.firewall¶

В этой главе мы рассмотрим настройку брандмауэра на примере сценария rc.firewall.txt. Мы будем брать каждую базовую настройку и рассматривать как она работает и что делает. Это может натолкнуть вас на решение ваших собственных задач. Для запуска этого сценария вам потребуется внести в него изменения таким образом, чтобы он мог работать с вашей конфигурацией сети, в большинстве случаев достаточно изменить только переменные.
Note

Примечательно, что есть более эффективные способы задания наборов правил, однако я исходил из мысли о большей удобочитаемости сценария, так, чтобы каждый смог понять его без глубоких познаний оболочки BASH.

7.1. Пример rc.firewall¶

Итак, все готово для разбора файла примера rc.firewall.txt (сценарий включен в состав данного документа в приложении Примеры сценариев). Он достаточно велик, но только из-за большого количества комментариев. Сейчас я предлагаю вам просмотреть этот файл, чтобы получить представление о его содержимом и затем вернуться сюда за более подробными пояснениями.

7.2. Описание сценария rc.firewall¶

7.2.1. Конфигурация

Первая часть файла rc.firewall.txt является конфигурационным разделом. Здесь задаются основные настройки брандмауэра, которые зависят от вашей конфигурации сети. Например IP адреса — наверняка должны быть изменены на ваши собственные. Переменная $INET_IP должна содержать реальный IP адрес, если вы подключаетесь к Интернет через DHCP, то вам следует обратить внимание на скрипт rc.DHCP.firewall.txt, Аналогично $INET_IFACE должна указывать ваше устройство, через которое осуществляется подключение к Интернет. Это может быть, к примеру, eth0, eth1, ppp0, tr0 и пр.

Этот сценарий не содержит каких либо настроек, специфичных для DHCP, PPPoE, поэтому эти разделы не заполнены. То же самое касается и других «пустых» разделов. Это сделано преднамеренно, чтобы вы могли более наглядно видеть разницу между сценариями. Если вам потребуется заполнить эти разделы, то вы можете взять их из других скриптов, или написать свой собственный.

Раздел Local Area Network должен содержать настройки, соответствующие конфигурации вашей локальной сети. Вы должны указать локальный IP адрес брандмауэра, интерфейс, подключенный к локальной сети, маску подсети и широковещательный адрес.

Далее следует секция Localhost Configuration, которую изменять вам едва ли придется. В этой секции указывается локальный интерфейс lo и локальный IP адрес 127.0.0.1. За разделом Localhost Configuration, следует секция Iptables Configuration. Здесь создается переменная $IPTABLES, содержащая путь к файлу iptables (обычно /usr/local/sbin/iptables). Если вы устанавливали iptables из исходных модулей, то у вас путь к iptables может несколько отличаться от приведенного в сценарии (например /usr/sbin/iptables), однако в большинстве дистрибутивов iptables расположена именно здесь.

7.2.2. Загрузка дополнительных модулей

В первую очередь, командой /sbin/depmod -a, выполняется проверка зависимостей модулей после чего производится подгрузка модулей, необходимых для работы сценария. Старайтесь в ваших сценариях загружать только необходимые модули. Например, по каким то причинам мы собрали поддержку действий LOG, REJECT и MASQUERADE в виде подгружаемых модулей и теперь собираемся строить правила, использующие эти действия, тогда соответствующие модули необходимо загрузить командами:

/sbin/insmod ipt_LOG
/sbin/insmod ipt_REJECT
/sbin/insmod ipt_MASQUERADE

Внимание!

В своих сценариях я принудительно загружаю все необходимые модули, во избежание отказов. Если происходит ошибка во время загрузки модуля, то причин может быть множество, но основной причиной является то, что подгружаемые модули скомпилированы с ядром статически. За дополнительной информацией обращайтесь к разделу Проблемы загрузки модулей.

В следующей секции приводится ряд модулей, которые не используются в данном сценарии, но перечислены для примера. Так например модуль ipt_owner, который может использоваться для предоставления доступа к сети с вашей машины только определенному кругу пользователей, повышая, тем самым уровень безопасности. Информацию по критериям ipt_owner, смотрите в разделе Критерий Owner главы Как строить правила.

Мы можем загрузить дополнительные модули для проверки «состояния» пакетов (state matching). Все модули, расширяющие возможности проверки состояния пакетов, именуются как ip_conntrack_* и ip_nat_*. С помощью этих модулей осуществляется трассировка соединений по специфичным протоколам. Например: протокол FTP является комплексным протоколом по определению, он передает информацию о соединении в области данных пакета. Так, если наш локальный хост передает через брандмауэр, производящий трансляцию адресов, запрос на соединение с FTP сервером в Интернет, то внутри пакета передается локальный IP адрес хоста. А поскольку, IP адреса, зарезервированные для локальных сетей, считаются ошибочными в Интернет, то сервер не будет знать что делать с этим запросом, в результате соединение не будет установлено. Вспомогательный модуль FTP NAT выполняет все необходимые действия по преобразованию адресов, поэтому FTP сервер фактически получит запрос на соединение от имени нашего внешнего IP адреса и сможет установить соединение. То же самое происходит при использовании DCC для передачи файлов и чатов. Установка соединений этого типа требует передачи IP адреса и порта по протоколу IRC, который так же проходит через трансляцию сетевых адресов на брандмауэре. Без специального модуля расширения работоспособность протоколов FTP и IRC становится весьма сомнительной. Например, вы можете принимать файлы через DCC, но не можете отправлять. Это обусловливается тем, как DCC «запускает» соединение. Вы сообщаете принимающему узлу о своем желании передать файл и куда он должен подключиться. Без вспомогательного модуля DCC соединение выглядит так, как если бы мы потребовали установление соединения внешнего приемника с узлом в нашей локальной сети, проще говоря такое соединение будет «обрушено». При использовании же вспомогательного модуля все работает прекрасно. поскольку приемнику передается корректный IP адрес для установления соединения.

Если у вас наблюдаются проблемы с прохождением mIRC DCC через брандмауэр, но при этом другие IRC-клиенты работают вполне корректно — прочитайте раздел Проблемы mIRC DCC в приложении Общие проблемы и вопросы.

Дополнительную информацию по модулям conntrack и nat читайте в приложении Общие проблемы и вопросы. Так же не забывайте о документации, включаемой в пакет iptables. Чтобы иметь эти дополнительные возможности, вам потребуется установить patch-o-matic и пересобрать ядро. Как это сделать — объясняется выше в главе Подготовка.

Заметьте, что загружать модули ip_nat_irc и ip_nat_ftp вам потребуется только в том случае, если вы хотите, чтобы преобразование сетевых адресов (Network Adress Translation) производилось корректно с протоколами FTP и IRC. Так же вам потребуется подгрузить модули ip_conntrack_irc и ip_conntrack_ftp до загрузки модулей NAT.

7.2.3. Настройка /proc

Здесь мы запускаем пересылку пакетов (IP forwarding), записав единицу в файл /proc/sys/net/ipv4/ip_forward таким способом:

echo «1» > /proc/sys/net/ipv4/ip_forward

Внимание!
bq. Наверное стоит задуматься над тем где и когда включать пересылку (IP forwarding). В этом и в других сценариях в данном руководстве, мы включаем пересылку до того как создадим какие либо правила iptables. От начала работы пересылки (IP forwarding) до момента, когда будут созданы необходимые правила, при нашем варианте, может пройти от нескольких миллисекунд до минут, все зависит от объема работы, выполняемой сценарием и быстродействия конкретного компьютера. Понятно, что это дает некоторый промежуток времени, когда злоумышленник может проникнуть через брандмауэр. Поэтому, в реальной ситуации запускать пересылку (IP forwarding) следует после создания всего набора правил. Здесь же я поместил включение пересылки в начале исключительно в целях удобочитаемости.

Если вам необходима поддержка динамического IP, (при использовании SLIP, PPP или DHCP) вы можете раскомментарить строку:

echo «1» > /proc/sys/net/ipv4/ip_dynaddr

Если вам требуется включить любые другие опции, вы должны обращаться к соответствующей документации по этим опциям. Хороший и лаконичный документ по файловой системе /proc поставляется вместе с ядром. Ссылки на на другие документы вы найдете в приложении Ссылки на другие ресурсы.

Сценарий rc.firewall.txt и все остальные сценарии в данном руководстве, содержат небольшую по размерам секцию не требуемых (non-required) настроек /proc. Как бы привлекательно не выглядели эти опции — не включайте их, пока не убедитесь, что достаточно четко представляете себе функции, которые они выполняют.

7.2.4. Размещение правил по разным цепочкам

Здесь мы поговорим о пользовательских цепочках, в частности — о пользовательских цепочках, определяемых в сценарии rc.firewall.txt. Мой вариант разделения правил по дополнительным цепочкам может оказаться неприемлемым в том или ином конкретном случае. Я надеюсь, что смогу показать вам возможные «подводные камни». Данный раздел тесно перекликается с главой Порядок прохождения таблиц и цепочек и совершенно нелишним будет еще раз, хотя бы бегло, просмотреть ее.

Распределив набор правил по пользовательским цепочкам, я добился экономии процессорного времени, без потери уровня безопасности системы и читабельности сценариев. Вместо того, чтобы пропускать TCP пакеты через весь набор правил (и для ICMP, и для UDP), я просто отбираю TCP пакеты и пропускаю их через пользовательскую цепочку, предназначенную именно для TCP пакетов, что приводит к уменьшению нагрузки на систему. На следующей картинке схематично приводится порядок прохождения пакетов через netfilter. В действительности, эта картинка выглядит несколько ограниченно по сравнению со схемой, приведенной в главе Порядок прохождения таблиц и цепочек.

Основное назначение рисунка — освежить нашу память. В целом, данный пример сценария основан на предположении, что мы имеем одну локальную сеть, один брандмауэр (firewall) и единственное подключение к Интернет, с постоянным IP адресом (в противоположность PPP, SLIP, DHCP и прочим). Так же предполагается, что доступ к сервисам Интернет идет через брандмауэр, что мы полностью доверяем нашей локальной сети и поэтому не собираемся блокировать траффик, исходящий из локальной сети, однако Интернет не может считаться доверительной сетью и поэтому необходимо ограничить возможность доступа в нашу локальную сеть извне. Мы собираемся исходить из принципа «Все что не разрешено — то запрещено». Для выполнения последнего ограничения, мы устанавливаем политику по-умолчанию — DROP. Тем самым мы отсекаем соединения, которые явно не разрешены.

А теперь давайте рассмотрим что нам нужно сделать и как.

Для начала — позволим соединения из локальной сети с Интернет. Для этого нам потребуется выполнить преобразование сетевых адресов (NAT). Делается это в цепочке PREROUTING (Я полагаю, что здесь автор просто допустил опечатку, поскольку в тексте сценария заполняется цепочка POSTROUTING, да и мы уже знаем, что SNAT производится в цепочке POSTROUTING таблицы nat прим. перев.), которая заполняется последней в нашем сценарии. Подразумевается, также, выполнение некоторой фильтрации в цепочке FORWARD. Если мы полностью доверяем нашей локальной сети, пропуская весь траффик в Интернет, то это еще не означает доверия к Интернет и, следовательно необходимо вводить ограничения на доступ к нашим компьютерам извне. В нашем случае мы допускаем прохождение пакетов в нашу сеть только в случае уже установленного соединения, либо в случае открытия нового соединения, но в рамках уже существующего (ESTABLISHED и RELATED).

Что касается машины-брандмауэра — необходимо до минимума свести сервисы, работающие с Интернет. Следовательно мы допускаем только HTTP, FTP, SSH и IDENTD доступ к брандмауэру. Все эти протоколы мы будем считать допустимыми в цепочке INPUT, соответственно нам необходимо разрешить «ответный» траффик в цепочке OUTPUT. Поскольку мы предполагаем доверительные взаимоотношения с локальной сетью, то мы добавляем правила для диапазона адресов локальной сети, а заодно и для локального сетевого интерфейса и локального IP адреса (127.0.0.1). Как уже упоминалось выше, существует ряд диапазонов адресов, выделенных специально для локальных сетей, эти адреса считаются в Интернет ошибочными и как правило не обслуживаются. Поэтому и мы запретим любой траффик из Интернет с исходящим адресом, принадлежащим диапазонам локальных сетей. И в заключение прочитайте главу Общие проблемы и вопросы.

Так как у нас работает FTP сервер, то правила, обслуживающие соединения с этим сервером, желательно было бы поместить в начало цепочки INPUT, добиваясь тем самым уменьшения нагрузки на систему. В целом же, надо понимать, что чем меньше правил проходит пакет, тем больше экономия процессорного времени, тем ниже нагрузка на систему. С этой целью я разбил набор правил на дополнительные цепочки.

В нашем примере я разбил пакеты на группы по их принадлежности к тому или иному протоколу. Для каждого типа протокола создана своя цепочка правил, например, tcp_packets, которая содержит правила для проверки всех допустимых TCP портов и протоколов. Для проведения дополнительной проверки пакетов, прошедших через одну цепочку, может быть создана другая. В нашем случае таковой является цепочка allowed. В этой цепочке производится дополнительная проверка отдельных характеристик TCP пакетов перед тем как принять окончательное решение о пропуске. ICMP пакеты следуют через цепочку icmp_packets. Здесь мы просто пропускаем все ICMP пакеты с указанным кодом сообщения. И наконец UDP пакеты. Они проходят через цепочку udp_packets, которая обрабатывает входящие UDP пакеты. Если они принадлежат допустимым сервисам, то они пропускаются без проведения дополнительной проверки.

Поскольку мы рассматриваем сравнительно небольшую сеть, то наш брандмауэр используется еще и в качестве рабочей станции, поэтому мы делаем возможным соединение с Интернет и с самого брандмауэра.

И в завершение о цепочке OUTPUT. Мы не выполняем каких либо специфичных блокировок для пользователей, однако мы не хотим, чтобы кто либо, используя наш брандмауэр выдавал в сеть «поддельные» пакеты, поэтому мы устанавливаем правила, позволяющие прохождение пакетов только с нашим адресом в локальной сети, с нашим локальным адресом (127.0.0.1) и с нашим адресом в Интернет. С этих адресов пакеты пропускаются цепочкой OUTPUT, все остальные (скорее всего сфальсифицированные) отсекаются политикой по-умолчанию DROP.

7.2.5. Установка политик по-умолчанию

Прежде, чем приступить к созданию набора правил, необходимо определиться с политиками цепочек по-умолчанию. Политика по-умолчанию устанавливается командой, подобной приводимой ниже

iptables [-P {chain} {policy}]

Политика по-умолчанию представляет собой действие, которое применяется к пакету, не попавшему под действие ни одного из правил в цепочке. (Небольшое уточнение, команда iptables -P применима ТОЛЬКО К ВСТРОЕННЫМ цепочкам, т.е. INPUT, FORWARD, OUTPUT и т.п., и не применима к пользовательским цепочкам. прим. перев.).

Будьте предельно осторожны с установкой политик по-умолчанию для цепочек из таблиц, не предназначенных для фильтрации, так как это может приводить к довольно странным результатам.

7.2.6. Создание пользовательских цепочек в таблице filter

Итак, у вас перед глазами наверняка уже стоит картинка движения пакетов через различные цепочки, и как эти цепочки взаимодействуют между собой! Вы уже должны ясно представлять себе цели и назначение данного сценария. Давайте начнем создавать цепочки и наборы правил для них.

Прежде всего необходимо создать дополнительные цепочки с помощью команды -N. Сразу после создания цепочки еще не имеют ни одного правила. В нашем примере создаются цепочки icmp_packets, tcp_packets, udp_packets и цепочка allowed, которая вызывается из цепочки tcp_packets. Входящие пакеты с интерфейса $INET_IFACE (т.е. из Интернет), по протоколу ICMP перенаправляются в цепочку icmp_packets, пакеты протокола TCP перенаправляются в цепочку tcp_packets и входящие пакеты UDP с интерфейса eth0 идут в цепочку udp_packets. Более подробное описание вы найдете в разделе Цепочка INPUT. Синтаксис команды для создания своей цепочки очень прост:

iptables [-N chain]

7.2.6.1. Цепочка bad_tcp_packets

Эта цепочка предназначена для отфильтровывания пакетов с «неправильными» заголовками и решения ряда других проблем. Здесь отфильтровываются все пакеты, которые распознаются как NEW, но не являются SYN пакетами, а так же обрабатываются SYN/ACK-пакеты, имеющие статус NEW. Эта цепочка может быть использована для защиты от вторжения и сканирования портов. Сюда, так же, добавлено правило для отсеивания пакетов со статусом INVALID.

Если вы пожелаете почитать более подробно об этой проблеме, то смотрите раздел Пакеты со статусом NEW и со сброшенным битом SYN в приложении Общие проблемы и вопросы. Разумеется, не всегда справедливо будет просто сбрасывать пакеты с признаком NEW и сброшенным битом SYN, но в 99% случаев это оправданный шаг. Поэтому мой сценарий заносит информацию о таких пакетах в чичтемный журнал, а затем «сбрасывает» их.

Причина, по которой для SYN/ACK-пакетов со статусом NEW @применяется действие @REJECT, достаточно проста. Она описывается в разделе SYN/ACK — пакеты и пакеты со статусом NEW приложения Общие проблемы и вопросы. Общепринятой считается необходимость отправления пакета RST в подобных случаях (RST в ответ на незапрошенный SYN/ACK). Тем самым мы предотвращаем возможность атаки «Предсказание номера TCP-последовательности» (Sequence Number Prediction) на другие узлы сети.

7.2.6.2. Цепочка allowed

TCP пакет, следуя с интерфейса $INET_IFACE, попадает в цепочку tcp_packets, если пакет следует на разрешенный порт, то после этого проводится дополнительная проверка в цепочке allowed.

Первое правило проверяет, является ли пакет SYN пакетом, т.е. запросом на соединение. Такой пакет мы считаем допустимым и пропускаем. Следующее правило пропускает все пакеты с признаком ESTABLISHED или RELATED. Когда соединение устанавливается SYN пакетом, и на этот запрос был отправлен положительный ответ, то оно получает статус ESTABLISHED. Последним правилом в этой цепочке сбрасываются все остальные TCP пакеты. Под это правило попадают пакеты из несуществующего соединения, пакеты со сброшенным битом SYN, которые пытаются запустить соединение. Не SYN пакеты практически не используются для запуска соединения, за исключением случаев сканирования портов. Насколько я знаю, на сегодняшний день нет реализации TCP/IP, которая поддерживала бы открытие соединения иначе, чем передача SYN пакета, поэтому на 99% можно быть уверенным, что сброшены пакеты, посланные сканером портов.

7.2.6.3. Цепочка для TCP

Итак, мы подошли к TCP соединениям. Здесь мы указываем, какие порты могут быть доступны из Internet. Несмотря на то, что даже если пакет прошел проверку здесь, мы все равно все пакеты передаем в цепочку allowed для дополнительной проверки.

Я открыл TCP порт с номером 21, который является портом управления FTP соединениями. и далее, я разрешаю все RELATED соединения, разрешая, тем самым, PASSIVE FTP, при условии, что был загружен модуль ip_conntrack_ftp. Если вам потребуется запретить FTP соединения, то вам потребуется выгрузить модуль ip_conntrack_ftp и удалить строку $IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 21 -j allowed из сценария rc.firewall.txt.

Порт 22 — это SSH, который намного более безопасен чем telnet на 23 порту. Если Вам вздумается предоставить доступ к командной оболочке (shell) кому бы то ни было из Интернет, то лучше конечно пользоваться SSH. Однако, хочу заметить, что вообще-то считается дурным тоном предоставлять доступ к брандмауэру любому кроме вас самих. Ваш сетевой экран должен иметь только те сервисы, которые действительно необходимы и не более того.

Порт 80 — это порт HTTP, другим словами — web сервер, уберите это правило, если у вас нет web сервера.

И наконец порт 113, ответственный за службу IDENTD и использующийся некоторыми протоколами типа IRC, и пр. Замечу, что вам следует использовать пакет oidentd если вы делаете трансляцию сетевых адресов для некоторых узлов (хостов) в локальной сети. oidentd поддерживает передачу IDENTD запросов в локальной сети.

Если у вас имеется необходимость открыть дополнительные порты, то просто скопируйте одно из правил в цепочке tcp_packets и подправьте номера портов в соответствии с вашими требованиями.

7.2.6.4. Цепочка для UDP

Пакеты UDP из цепочки INPUT следуют в цепочку udp_packets Как и в случае с TCP пакетами, здесь они проверяются на допустимость по номеру порта назначения. Обратите внимание — мы не проверяем исходящий порт пакета, поскольку об этом заботится механизм определения состояния. Открываются только те порты, которые обслуживаются серверами или демонами на нашем брандмауэре. Пакеты, которые поступают на брандмауэр по уже установленным соединениям (установленным из локальной сети) пропускаются брандмауэром автоматически, поскольку имеют состояние ESTABLISHED или RELATED.

Как видно из текста сценария, порт 53, на котором «сидит» DNS, для UDP пакетов закрыт, то есть правило, открывающее 53-й порт в сценарии присутствует, но закомментировано. Если вы пожелаете запустить DNS на брандмауэре, то это правило следует раскомментировать.

Я лично разрешаю порт 123, на котором работает NTP (network time protocol). Этой службой обычно пользуются для приема точного времени с серверов времени в Интернет. Однако, вероятнее всего, что вы не используете этот протокол, поэтому соответствующее правило в сценарии так же закомментировано.

Порт 2074 используется некоторыми мультимедийными приложениями, подобно speak freely, которые используются для передачи голоса в режиме реального времени.

И наконец — ICQ, на порту 4000. Это широко известный протокол, используемый ICQ-приложениями Я полагаю, не следует объяснять вам что это такое.

Кроме того в сценарии приведены еще два правила, которые по-умолчанию закомментированы. Ими можно воспользоваться, если брандмауэр чрезмерно нагружен. Первое — блокирует широковещательные пакеты, поступающие на порты со 135 по 139. Эти порты используются протоколами SMB и NetBIOS от Microsoft. Таким образом данное правило предотвращает переполнение таблицы трассировщика в сетях Microsoft Network. Второе правило блокирует DHCP запросы извне. Это правило определенно имеет смысл если внешняя сеть содержит некоммутируемые сегменты, где IP адреса выделяются клиентам динамически.

Последние два правила не являются обязательными (в тексте сценария они закомментированы). Все пакеты, которые не были отвергнуты или приняты явно, логируются в журнал последним правилом в цепочке INPUT, поэтому, если вас беспокоит проблема «раздувания» системного журнала — можете раскомментировать эти правила.

7.2.6.5. Цепочка для ICMP

Здесь принимается решение о пропуске ICMP пакетов. Если пакет приходит с eth0 в цепочку INPUT, то далее он перенаправляется в цепочку icmp_packets. В этой цепочке проверяется тип ICMP сообщения. Пропускаются только ICMP Echo Request, TTL equals 0 during transit и TTL equals 0 during reassembly. Все остальные типы ICMP сообщений должны проходить брандмауэр беспрепятственно, поскольку будут иметь состояние RELATED.

Если ICMP пакет приходит в ответ на наш запрос, то он приобретает статус RELATED (связанный с имеющимся соединением). Более подробно состояние пакетов рассматривается в главе Механизм определения состояний

При принятии решения я исхожу из следующих соображений: ICMP Echo Request пакеты посылаются, главным образом, для проверки доступности хоста. Если удалить это правило, то наш брандмауэр не будет «откликаться» в ответ на ICMP Echo Request, что сделает использование утилиты ping и подобных ей, по отношению к брандмауэру, бесполезными.

Time Exceeded (т.е., TTL equals 0 during transit и TTL equals 0 during reassembly). Во время движения пакета по сети, на каждом маршрутизаторе поле TTL, в заголовке пакета, уменьшается на 1. Как только поле TTL станет равным нулю, то маршрутизатором будет послано сообщение Time Exceeded. Например, когда вы выполняете трассировку (traceroute) какого либо узла, то поле TTL устанавливается равным 1, на первом же маршрутизаторе оно становится равным нулю и к нам приходит сообщение Time Exceeded, далее, устанавливаем TTL = 2 и второй маршрутизатор передает нам Time Exceeded, и так далее, пока не получим ответ с самого узла.

Список типов ICMP сообщений смотрите в приложении Типы ICMP. Дополнительную информацию по ICMP вы можете получить в следующих документах:

The Internet Control Message Protocol
«RFC 792 — Internet Control Message Protocol — от J. Postel»:

Будьте внимательны при блокировании ICMP пакетов, возможно я не прав, блокируя какие-то из них, может оказаться так, что для вас это неприемлемо.

7.2.7. Цепочка INPUT

Цепочка INPUT, как я уже писал, для выполнения основной работы использует другие цепочки, за счет чего снижая нагрузку на сетевой фильтр. Эффект применения такого варианта организации правил лучше заметен на медленных машинах, которые в другом случае начинают «терять» пакеты при высокой нагрузке. Достигается это разбиением набора правил по некоторому признаку и выделение их в отдельные цепочки. Тем самым уменьшается количество правил, которое проходит каждый пакет.

Первым же правилом мы пытаемся отбросить «плохие» пакеты. За дополнительной информацией обращайтесь к приложению Цепочка bad_tcp_packets. В некоторых особенных ситуациях такие пакеты могут считаться допустимыми, но в 99% случаев лучше их «остановить». Поэтому такие пакеты заносятся в системный журнал (логируются) и «сбрасываются».

Далее следует целая группа правил, которая пропускает весь трафик, идущий из доверительной сети, которая включает в себя сетевой адаптер, связанный с локальной сетью и локальный сетевой интерфейс (lo) и имеющий исходные адреса нашей локальной сети (включая реальный IP адрес). Эта группа правил стоит первой по той простой причине, что локальная сеть генерирует значительно бОльший трафик чем трафик из Internet. Поэтому, при построении своих наборов правил, всегда старайтесь учитывать объем трафика, указывая первыми те правила, которые будут обслуживать больший трафик.

Первым в группе, анализирующей трафик идущий с $INET_IFACE, стоит правило, пропускающее все пакеты со статусом ESTABLISHED или RELATED (эти пакеты являются частью уже УСТАНОВЛЕННОГО или СВЯЗАННОГО соединения). Это правило эквивалентно правилу, стоящему в цепочке allowed. И в некоторой степени является избыточным, поскольку затем цепочка allowed вызывается опосредованно через цепочку tcp_packets, однако оно несколько разгружает сетевой фильтр, поскольку значительная доля трафика пропускается этим праилом и не проходит всю последовательность до цепочки allowed.

После этого производится анализ трафика, идущего из Internet. Все пакеты, приходящие в цепочку INPUT с интерфейса $INET_IFACE распределяются по вложенным цепочкам, в зависимости от типа протокола. TCP пакеты передаются в цепочку tcp_packets, UDP пакеты отправляются в цепочку udp_packets и ICMP перенаправляются в цепочку icmp_packets. Как правило, большую часть трафика «съедают» TCP пакеты, потом UDP и меньший объем приходится на долю ICMP, однако в вашем конкретном случае это предположение может оказаться неверным. Очень важно учитывать объем трафика, проходящего через набор правил. Учет объема трафика — абсолютная необходимость. В случае неоптимального распределения правил даже машину класса Pentium III и выше, с сетевой картой 100 Мбит и большим объемом передаваемых данных по сети, довольно легко можно «поставить на колени» сравнительно небольшим объемом правил.

Далее следует весьма специфическое правило (по-умолчанию закомментировано). Дело в том, что клиенты Microsoft Network имеют «дурную привычку» выдавать огромное количество Multicast (групповых) пакетов в диапазоне адресов 224.0.0.0/8. Поэтому можно использовать данное правило для предотвращения «засорения» логов в случае, если с внешней стороны имеется какая либо сеть Microsoft Network. Подобную же проблему решают два последних правила (по-умолчанию закомментированы) в цепочке udp_packets, описанные в Цепочка для UDP.

Последним правилом, перед тем как ко всем не принятым явно пакетам в цепочке INPUT будет применена политика по-умолчанию, траффик журналируется, на случай необходимости поиска причин возникающих проблем. При этом мы устанавливаем правилу, ограничение на количество логируемых пакетов — не более 3-х в минуту, чтобы предотвратить чрезмерное раздувание журнала и кроме того подобные записи в журнал сопровождаются собственным комментарием (префиксом), чтобы знать откуда появились эти записи.

Все что не было явно пропущено в цепочке INPUT будет подвергнуто действию DROP, поскольку именно это действие назначено в качестве политики по-умолчанию. Политики по-умолчанию были описаны чуть выше в разделе У_становка политик по-умолчанию_.

7.2.8. Цепочка FORWARD

Цепочка FORWARD содержит очень небольшое количество правил. Первое правило напрвляет все TCP пакеты на проверку в цепочку bad_tcp_packets, которая используется так же и в цепочке INPUT. Цепочка bad_tcp_packets сконструирована таким образом, что может вызываться из других цепочек, невзирая на то, куда направляется пакет. После проверки TCP пакетов, как обычно, мы разрешем движение пакетов из локальной сети без ограничений.

Далее, пропускается весь трафик из локальной сети без ограничений. Естественно, нужно пропустить ответные пакеты в локальную сеть, поэтому следующим правилом мы пропускаем все, что имеет признак ESTABLISHED или RELATED, т.е. мы пропускаем пакеты по соединению установленному ИЗ локальной сети.

И в заключение заносим в системный журнал информацию о сброшенных пакетах, предваряя их префиксом "IPT FORWARD packet died: ", чтобы потом, в случае поиска ошибок, не перепутать их с пакетами, сброшенными в цепочке INPUT.

7.2.9. Цепочка OUTPUT

Как я уже упоминал ранее, в моем случае компьютер используется как брандмауэр и одновременно как рабочая станция. Поэтому я позволяю покидать мой хост всему, что имеет исходный адрес $LOCALHOST_IP@, $LAN_IP@ или $STATIC_IP. Сделано это для защиты от трафика, который может сфальсицироваться моего компьютера, несмотря на то, что я совершенно уверен во всех, кто имеет к нему доступ. И в довершение ко всему, я журналирую «сброшенные» пакеты, на случай поиска ошибок или в целях выявления сфальсифицированных пакетов. Ко всем пакетам, не прошедшим ни одно из правил, применяется политика по-умолчанию -- DROP.

7.2.10. Цепочка PREROUTING таблицы nat

В данном сценарии эта цепочка не имеет ни одного правила и единственно, почему я привожу ее описание здесь, это еще раз напомнить, что в данной цепочке выполняется преобразование сетевых адресов (DNAT) перед тем как пакеты попадут в цепочку INPUT или FORWARD.

Еще раз хочу напомнить, что эта цепочка не предназначена ни для какого вида фильтрации, а только для преобразования адресов, поскольку в эту цепочку попадает только первый пакет из потока.

7.2.11. Запуск SNAT и цепочка POSTROUTING

И заключительный раздел — настройка SNAT. По крайней мере для меня. Прежде всего мы добавляем правило в таблицу nat, в цепочку POSTROUTING, которое производит преобразование исходных адресов всех пакетов, исходящих с интерфейса, подключенного к Internet. В сценарии определен ряд переменных, с помощью которых можно использовать для автоматической настройки сценария. Кроме того, использование переменных повышает удобочитаемость скриптов. Ключом -t задается имя таблицы, в данном случае nat. Команда -A добавляет (Add) новое правило в цепочку POSTROUTING, критерий -o $INET_IFACE задает исходящий интерфейс, и в конце правила задаем действие над пакетом --SNAT. Таким образом, все пакеты, подошедшие под заданный критерий будут «замаскированы», т.е. будут выглядеть так, как будто они отправлены с нашего узла. Не забудьте указать ключ --to-source с соответствующим IP адресом для исходящих пакетов

В этом сценарие я использую SNAT вместо MASQUERADE по ряду причин. Первая — предполагается, что этот сценарий должен работать на сетевом узле, который имеет постоянный IP адрес. Следующая состоит в том, что SNAT работает быстрее и более эффективно. Конечно, если вы не имеете постоянного IP адреса, то вы должны использовать действие MASQUERADE, которое предоставляет более простой способ трансляции адресов, поскольку оно автоматически определяет IP адрес, присвоенный заданному интерфейсу. Однако, по сравнению с SNAT это действие требует несколько больших вычислительных ресурсов, хотя и не значительно. Пример работы с MASQUERADE, вы найдете в сценарии rc.DHCP.firewall.txt

Глава 8. Примеры сценариев¶

Цель этой главы состоит в том, чтобы дать краткое описание каждого сценария, в этом руководстве. Эти сценарии не совершенны, и они не могут полностью соответствовать вашим нуждам. Это означает, что вы должны сами «подогнать» эти сценарии под себя. Последующая часть руководства призвана облегчить вам эту подгонку.

8.1. Структура файла rc.firewall.txt¶

Все сценарии, описанные в этом руководстве, имеют определенную структуру. Сделано это для того, чтобы сценарии были максимально похожи друг на друга, облегчая тем самым поиск различий между ними. Эта структура довольно хорошо описывается в этой главе. Здесь я надеюсь дать вам понимание, почему все сценарии были написаны именно так и почему я выбрал именно эту структуру.

Обратите внимание на то, что эта структура может оказаться далеко неоптимальной для ваших сценариев. Эта структура выбрана лишь для лучшего объяснения хода моих мыслей.

8.1.1. Структура¶

Это — структура, которой следуют все сценарии в этом руководстве. Если вы обнаружите, что это не так, то скорее всего это моя ошибка, если конечно я не объяснил, почему я нарушил эту структуру.

Configuration — Прежде всего мы должны задать параметры конфигурации, для сценария. Параметры Конфигурации, в большинстве случаев, должны быть описаны первыми в любом сценарии.
1. Internet — Это раздел конфигурации, описывающей подключение к Internet. Этот раздел может быть опущен, если вы не подключены к Интернет. Обратите внимание, что может иметься большее количество подразделов чем, здесь перечислено, но только те, которые описывают наше подключение к Internet.
  1. DHCP — Если имеются специфичные для DHCP настройки, то они добавляются здесь.
  2. PPPoE — Описываются параметры настройки PPPoE подключения.
2. LAN — Если имеется любая ЛОКАЛЬНАЯ СЕТЬ за брандмауэром, то здесь указываются параметры, имеющие отношение к ней. Наиболее вероятно, что этот раздел будет присутствовать почти всегда.
3. DMZ — Здесь добавляется конфигурация зоны DMZ. В большинстве сценариев этого раздела не будет, т.к. любая нормальная домашняя сеть, или маленькая локальная сеть, не будет иметь ее. (DMZ - de-militarized zone. Скорее всего под это понятие автор подвел небольшую подсеть, в которой расположены серверы, например: DNS, MAIL, WEB и т.п, и нет ни одной пользовательской машины. прим. перев.)
4. Localhost — Эти параметры принадлежат нашему брандмауэру (localhost). В вашем случае эти переменные вряд ли изменятся, но, тем не менее, я создал эти переменные.Хотелось бы надеяться, что у вас не будет причин изменять эти переменные.
5. iptables — Этот раздел содержит информацию об iptables. В большинстве сценариев достаточно будет только одной переменной, которая указывает путь к iptables.
6. Other — Здесь располагаются прочие настройки, которые не относятся и к одному из вышеуказанных разделов.
Module loading — Этот раздел сценариев содержит список модулей. Первая часть должна содержать требуемые модули, в то время как вторая часть должна содержать нетребуемые модули.
bq. Обратить внимание. Некоторые модули, отвечающие за дополнительные возможности, могут быть указаны даже если они не требуются. Обычно, в таких случаях, пример сценария отмечает эту особенность.
1. Required modules — Этот раздел должен содержать модули, необходимые для работы сценария.
2. Non-required modules — Этот раздел содержит модули, которые не требуются для нормальной работы сценария. Все эти модули должны быть закомментированы. Если вам они потребуются, то вы должны просто раскомментировать их.
proc configuration — Этот раздел отвечает за настройку файловой системы /proc. Если эти параметры необходимы — они будут перечислены, если нет, то они должны быть закомментированы по-умолчанию, и указаны как не-требуемые. Большинство полезных настроек /proc будут перечислены в примерах, но далеко не все.
1. Required proc configuration — Этот раздел должен содержать все требуемые сценарием настройка для /proc. Это могут быть настройки для запуска системы защиты, возможно, добавляют специальные возможности для администратора или пользователей.
2. Non-required proc configuration — Этот раздел должен содержать не-требуемые настройки /proc, которые могут оказаться полезными в будущем. Все они должны быть закомментированы, так как они фактически не требуются для работы сценария. Этот список будет содержать далеко не все настройки /proc.
rules set up — К этому моменту скрипт, как правило, уже подготовлен к тому, чтобы вставлять наборы правил. Я разбил все правила по таблицам и цепочкам. Любые пользовательские цепочки должны быть созданы прежде, чем мы сможем их использовать. Я указываю цепочки и их наборы правил в том же порядке, в каком они выводятся командой iptables -L.
1. Filter table — Прежде всего мы проходим таблицу filter. Для начала необходимо установить политику по умолчанию в таблице.
2. Set policies — Назначение политик по-умолчанию для системных цепочек. Обычно я устанавливаю DROP для цепочек в таблице filter, и буду пропускать потоки, которые идут изнутри. Тем самым мы избавимся от всего, что нам неугодно.
3. Create user specified chains — В этом разделе, создаются все пользовательские цепочки, которые мы будем использовать позже в пределах этой таблицы. Мы не сможем использовать эти цепочки в до тех пор, пока не создадим их.
4. Create content in user specified chains — После создания пользовательских цепочек, мы можем заполнить их правилами. Единственная причина, по которой правила для пользовательских цепочек определяются здесь — это близость к командам, создающим эти цепочки. Вы же можете размещать правила в другом месте вашего сценария.
5. INPUT chain — В этом разделе добавляются правила для цепочки INPUT.
  bq. Как уже указывалось, я старался следовать порядку, который получается в выводе команды iptables -L. Нет серьезных причин, чтобы соблюдать эту структуру, однако, пробуйте избежать смешивания данных из различных таблиц и цепочек, так как станет намного тяжелее читать такой набор правил и выискивать возможные проблемы.
6. FORWARD chain — Здесь мы добавляем правила в цепочку FORWARD
7. OUTPUT chain — амой последней в таблице filter, заполняется цепочка OUTPUT.
nat table — После таблицы filter мы переходим к таблице nat. Сделано это по ряду причин. Прежде всего — не следует запускать механизм NAT на ранней стадии, когда еще возможна передача пакетов без ограничений (то есть, когда NAT уже включена, но нет ни одного правила фильтрации). Также, я рассматриваю таблицу nat как своего рода уровень, который находится вне таблицы filter. Таблица filter является своего рода ядром, в то время как nat — оболочка вокруг ядра, а таблица mangle. может рассматриваться как оболочка вокруг таблицы nat. Это может быть не совсем правильно, но и не далеко от действительности.
1. Set policies — Прежде всего мы устанавливаем всю политику по умолчанию в пределах таблицы nat. Обычно, я устанавливаю ACCEPT. Эта таблица не должна использоваться для фильтрации, и мы не должны здесь «выбрасывать» (DROP) пакеты. Есть ряд неприятных побочных эффектов которые имеют место быть в таких случаях из-за наших предположений. Я пропускаю все пакеты в этих цепочках, поскольку не вижу никаких причин не делать этого.
2. Create user specified chains — Здесь создаются все пользовательские цепочки для таблицы nat. Обычно у меня их нет, но я добавил этот раздел на всякий случай. Обратите внимание, что пользовательские цепочки должны быть созданы до их фактического использования.
3. Create content in user specified chains — Добавление правил в пользовательские цепочки таблицы nat. Принцип размещения правил здесь тот же что и в таблице filter. Я добавляю их здесь потому, что не вижу причин выносить их в другое место.
4. PREROUTING chain — Цепочка PREROUTING используется для DNAT. В большинстве сценариев DNAT не используется, или по крайней мере закомментирована, чтобы не «открывать ворота» в нашу локальную сеть слишком широко. В некоторых сценариях это правило включено, так как единственная цель этих сценариев состоит в предоставлении услуг, которые без DNAT невозможны.
5. POSTROUTING chain — Цепочка POSTROUTING используется сценариями, которые я написал, так как в большинстве случаев имеется одна или более локальных сетей, которые мы хотим подключить к Интернет через сетевой экран. Главным образом мы будем использовать SNAT, но в некоторых случаях, мы вынуждены будем использовать MASQUERADE.
6. OUTPUT chain — Цепочка OUTPUT используется вообще в любом из сценариев. Но я пока не нашел серьезных оснований для использования этой цепочки. Если вы используете эту цепочку, черкните мне пару строк, и я внесу соответствующие изменения в данное руководство.
mangle table — Таблица mangle — последняя таблица на пути пакетов. Обычно я не использую эту таблицу вообще, так как обычно не возникает потребностей в чем либо, типа изменения TTL поля или поля TOS и пр. Другими словами, я оставил этот раздел пустым в некоторых сценариях, с несколькими исключениями, где я добавил, несколько примеров использования этой таблицы.
1. Set policies — Здесь задается Политика по-умолчанию. Здесь существуют те же ограничения, что и для таблицы nat. Таблица не должна использоваться для фильтрации, и следовательно вы должны избегать этого. Я не устанавливал никакой политики в любом из сценариев для цепочек в таблице mangle, и вам следут поступать так же.
2. Create user specified chains — Создаются пользовательские цепочки. Так как я не использую таблицу mangle в сценариях, я не стал создавать пользовательских цепочек. Однако, этот раздел был добавлен на всякий случай.
3. Create content in user specified chains — Если вы создали какие либо пользовательские цепочки в пределах этой таблицы, вы можете заполнить их правилами здесь.
4. PREROUTING — В этом пункте имеется только упоминание о цепочке.
5. INPUT chain — В этом пункте имеется только упоминание о цепочке.
6. FORWARD chain — В этом пункте имеется только упоминание о цепочке.
7. OUTPUT chain — В этом пункте имеется только упоминание о цепочке.
8. POSTROUTING chain — В этом пункте имеется только упоминание о цепочке.

Надеюсь, что я объяснил достаточно подробно, как каждый сценарий структурирован и почему они структурированы таким способом.

Обратите внимание, что эти описания чрезвычайно кратки, и являются лишь кратким пояснением того, почему сценарии имеют такую структуру. Я не претендую на истину в последней инстанции и не утверждаю, что это — единственный и лучший вариант.

8.2. rc.firewall.txt¶

Сценарий rc.firewall.txt — основное ядро, на котором основывается остальные сценарии. Глава Файл rc.firewall достаточно подробно описывает сценарий. Сценарий написан для домашней сети, где вы имеете одну ЛОКАЛЬНУЮ СЕТЬ и одно подключение к Internet. Этот сценарий также исходит из предположения, что вы имеете статический IP адрес, и следовательно не используете DHCP, PPP, SLIP либо какой то другой протокол, который назначает IP динамически. В противном случае возьмите за основу сценарий rc.DHCP.firewall.txt

Сценарий требует, чтобы следующие опции были скомпилированы либо статически, либо как модули. Без какой либо из них сценарий будет неработоспособен. Кроме того, изменения, которые вы возможно внесете в текст сценария, могут потребовать включения дополнительных возможностей в ваше ядро.

CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_TARGET_LOG

8.3. rc.DMZ.firewall.txt¶

Сценарий @rc.DMZ.firewall.txt был написан для тех, кто имеет доверительную локальную сеть, одну «Демилитаризированную Зону» и одно подключение к Internet. Для доступа к серверам Демилитаризированной Зоны, в данном случае, извне, используется NAT «один к одному», то есть, Вы должны заставить брандмауэр распознавать пакеты более чем для одного IP адреса.

Сценарий требует, чтобы следующие опции были скомпилированы либо статически, либо как модули. Без какой либо из них сценарий будет неработоспособен

CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_TARGET_LOG

Сценарий работает с двумя внутренними сетями, как это продемонстрировано на рисунке. Одна использует диапазон IP адресов 192.168.0.0/24 и является Доверительной Внутренней Сетью. Другая использует диапазон 192.168.1.0/24 и называется Демилитаризированной Зоной (DMZ), для которой мы будем выполнять преобразование адресов (NAT) «один к одному». Например, если кто-то из Интернет отправит пакет на наш DNS_IP, то мы выполним DNAT для передачи пакета на DNS в DMZ. Если бы DNAT не выполнялся, то DNS не смог бы получить запрос, поскольку он имеет адрес DMZ_DNS_IP, а не DNS_IP. Трансляция выполняется следующим правилом:

$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $DNS_IP \
--dport 53 -j DNAT --to-destination $DMZ_DNS_IP

Для начала напомню, что DNAT может выполняться только в цепочке PREROUTING таблицы nat. Согласно этому правилу, пакет должен приходить по протоколу TCP на $INET_IFACE с адресатом IP, который соответствует нашему $DNS_IP, и направлен на порт 53. Если встречен такой пакет, то выполняется подмена адреса назначения, или DNAT. Действию DNAT передается адрес для подмены с помощью ключа --to-destination $DMZ_DNS_IP. Когда через брандмауэр возвращается пакет ответа, то сетевым кодом ядра адрес отправителя будет автоматически изменен с $DMZ_DNS_IP на $DNS_IP, другими словами обратная детрансляция адресов выполняется автоматически и не требует создания дополнительных правил.

Теперь вы уже должны понимать как работает DNAT, чтобы самостоятельно разобраться в тексте сценария без каких либо проблем. Если что-то для вас осталось не ясным и это не было рассмотрено в данном документе, то вы можете сообщить мне об этом — вероятно, это моя ошибка.

8.4. rc.DHCP.firewall.txt¶

Сценарий The rc.DHCP.firewall.txt очень похож на оригинал rc.firewall.txt. Однако, этот сценарий больше не использует переменную STATIC_IP, это и является основным отличием от оригинала rc.firewall.txt. Причина в том, что rc.firewall.txt не будет работать в случае динамического IP адреса. Изменения, по сравнению с оригиналом — минимальны. Этот сценарий будет полезен в случае DHCP, PPP и SLIP подключения к Интернет.

CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_TARGET_MASQUERADE
CONFIG_IP_NF_TARGET_LOG

Главное отличие данного скрипта состоит в удалении переменной STATIC_IP и всех ссылок на эту переменную. Вместо нее теперь используется переменная INET_IFACE. Другими словами -d $STATIC_IP заменяется на -i $INET_IFACE. Собственно, это все, что нужно изменить в действительности. (Хочется отметить, что в данном случае под STATIC_IP автор понимает переменную INET_IP прим. перев.)

Мы больше не можем устанавливать правила в цепочке INPUT подобных этому: --in-interface $LAN_IFACE --dst $INET_IP. Это в свою очередь вынуждает нас строить правила основываясь только на сетевом интерфейсе. Например, пусть на брандмауэре запущен HTTP сервер. Если мы приходим на главную страничку, содержащую статическую ссылку обратно на этот же сервер, который работает под динамическим адресом, то мы можем «огрести» немало проблем. Хост, который проходит через NAT, запросит через DNS IP адрес HTTP сервера, после чего попробует получить доступ к этому IP. Если брандмауэр производит фильтрацию по интерфейсу и IP адресу, то хост не сможет получить ответ, поскольку цепочка INPUT отфильтрует такой запрос. Это так же справедливо и для некоторых случаев когда мы имеем статический IP адрес, но тогда это можно обойти, используя правила, которые проверяют пакеты, приходящие с LAN интерфейса на наш INET_IP и выполнять ACCEPT для них.

После всего вышесказанного, не такой уж плохой может показаться мысль о создании сценария, который бы обрабатывал динамический IP. Например, можно было бы написать скрипт, который получает IP адрес через ifconfig и подставляет его в текст сценария (где определяется соответствующая переменная), который «поднимает» соединение с Интернет. Замечательный сайт linuxguruz.org имеет огромную коллекцию скриптов, доступных для скачивания. Ссылку на linuxguruz.org вы найдете в приложении Ссылки на другие ресурсы.

Этот сценарий менее безопасен чем rc.firewall.txt. Я настоятельно рекомендую вам использовать сценарий rc.firewall.txt, если это возможно, так как rc.DHCP.firewall.txt более открыт для нападений извне.

Также, можно добавить в ваши сценарии что нибудь вроде этого:

INET_IP=`ifconfig $INET_IFACE | grep inet | cut -d : -f 2 | \
cut -d ‘ ‘ -f 1`

Выше приведенная команда получает динамический IP от интерфейса. Более совершенные методы получения IP адреса вы найдете в сценарии retreiveip.txt. Однако у такого подхода есть серьезные недостатки, которые описанны ниже.

Если скрипт запускается из другого сценария, который в свою очередь запускается демоном PPP, то это может привести к «зависанию» всех, уже установленных соединений, из-за правил, которые отбраковывают пакеты со статусом NEW и со сброшенным битом SYN. (смотри раздел Пакеты со статусом NEW и со сброшенным битом SYN). Проблему конечно можно разрешить удалением этих правил, но такое решение довольно сомнительно с точки зрения безопасности.
Предположим, что у вас есть набор статических правил, довольно грубо будет постоянно стирать и добавлять правила, к тому же рискуя повредить существующие.
Это может привести к излишним усложнениям, что в свою очередь, влечет ослабление защиты. Чем проще скрипт, тем проще его сопровождать.

8.5. rc.UTIN.firewall.txt¶

Сценарий rc.UTIN.firewall.txt, в отличие от других сценариев, блокирует LAN, которая находится за брандмауэром. Мы доверяем внутренним пользователям не больше чем пользователям из Internet. Другими словами, мы не доверяем никому, ни в Интернет, ни в локальной сети, с которыми мы связаны. Поэтому доступ к Интернет ограничивается только протоколами POP3, HTTP и FTP.

Этот сценарий следует золотому правилу — «не доверяй никому, даже собственным служащим». Это грустно но факт — большая часть атак и взломов, которым подвергается компания, производится служащими компаний из локальных сетей. Этот сценарий, надеюсь, даст некоторые сведения, которые помогут вам усилить вашу межсетевую защиту. Он мало отличается от оригинала rc.firewall.txt, но содержит подсказки о том, что мы обычно пропускаем.

Сценарий требует, чтобы следующие опции были скомпилированы либо статически, либо как модули. Без какой либо из них сценарий будет неработоспособен:

CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_TARGET_LOG

8.6. rc.test-iptables.txt¶

Сценарий rc.test-iptables.txt предназначен для проверки различных цепочек но может потребовать дополнительных настроек, в зависимости от вашей конфигурации, например, включения ip_forwarding или настройки masquerading и т.п. Тем не менее в большинстве случаев с базовыми настройками, когда настроены основные таблицы, этот сценарий будет работоспособен. В действительности, в этом сценарии производится установка действий LOG на ping-запросы и ping-ответы. Таким способом появляется возможность зафиксировать в системном журнале какие цепочки проходились и в каком порядке. Запустите сценарий и затем выполните следующие команды:

ping -c 1 host.on.the.internet

И во время исполнения первой команды выполните tail -n 0 -f /var/log/messages. Теперь вы должны ясно видеть все используемые цепочки и порядок их прохождения.
Note

Этот сценарий был написан исключительно в демонстрационных целях. Другими словами, не следует иметь правила для журналирования подобно этим, которые регистрируют все пакеты без ограничений. В противном случае вы рискуете стать легкой добычей для злоумышленника, который может засыпать вас пакетами, «раздуть» ваш лог, что может вызвать «Отказ в обслуживании», а после этого перейти к реальному взлому вашей системы не боясь быть обнаруженным, поскольку не сможет быть зарегистрирован системой.

8.7. rc.flush-iptables.txt¶

Сценарий rc.flush-iptables.txt в действительности не имеет самостоятельной ценности поскольку он сбрасывает все ваши таблицы и цепочки. В начале сценария, устанавливаются политики по-умолчанию ACCEPT для цепочек INPUT, OUTPUT и FORWARD в таблице filter. После этого сбрасываются в заданную по-умолчанию политики для цепочек PREROUTING, POSTROUTING и OUTPUT таблицы nat. Эти действия выполняются первыми, чтобы не возникало проблем с закрытыми соединениями и блокируемыми пакетами. Фактически, этот сценарий может использоваться для подготовки брандмауэра к настройке и при отладке ваших сценариев, поэтому здесь мы заботимся только об очистке набора правил и установке политик по-умолчанию.

Когда выполнена установка политик по-умолчанию, мы переходим к очистке содержимого цепочек в таблицах filter и nat, а затем производится удаление всех, определенных пользователем, цепочек. После этого работа скрипта завершается. Если вы используете таблицу mangle, то вы должны будете добавить в сценарий соответствующие строки для обработки этой таблицы.

В заключение пару слов. Очень многие спрашивают меня, а почему бы не поместить вызов этого сценария в rc.firewal, написав что-нибудь типа rc.firewall start для запуска скрипта. Я не сделал этого до сих пор, потому что считаю, что учебный материал должен нести в себе основные идеи и не должен быть перегружен разнообразными сценариями со странным синтаксисом. Добавление специфичного синтаксиса делает сценарии менее читабельными, а сам учебный материал более сложным в понимании, поэтому данное руководство остается таким, каково оно есть, и продолжит оставаться таким.

8.8. Limit-match.txt¶

Сценарий limit-match.txt написан с целью продемонстрировать работу с критерием limit. Запустите этот скрипт и попробуйте отправлять на этот хост ping-пакеты с различными интервалами.

8.9. Pid-owner.txt¶

Сценарий pid-owner.txt демонстрирует использование критерия --pid-owner. Фактически, этот сценарий ничего не блокирует, поэтому, чтобы увидеть его действие, вам потребуется воспользоваться командой iptables -L -v.

8.10. Sid-owner.txt¶

Сценарий sid-owner.txt демонстрирует использование критерия --sid-owner. Фактически, этот сценарий ничего не блокирует, поэтому, чтобы увидеть его действие, вам потребуется воспользоваться командой iptables -L -v.

8.11. Ttl-inc.txt¶

Небольшой пример ttl-inc.txt, демонстрирующий как можно сделать брандмауэр/роутер «невидимым» для трассировщиков, осложняя тем самым работу атакующего.

8.12. Iptables-save ruleset¶

Небольшой пример iptsave-saved.txt, о котором говорилось в главе Сохранение и восстановление больших наборов правил, иллюстрирующий работу команды iptables-save. Не является исполняемым сценарием и предназначен лишь для демонстрации результата работы iptables-save.

Приложение A. Детальное описание специальных команд¶

A.1. Вывод списка правил¶

Чтобы вывести список правил нужно выполнить команду iptables с ключом L, который кратко был описан ранее в главе Как строить правила. Выглядит это примерно так:

iptables -L

Эта команда выведет на экран список правил в удобочитаемом виде. Номера портов будут преобразованы в имена служб в соответствии с файлом /etc/services, IP адреса будут преобразованы в имена хостов через разрешение имен в службе DNS. С разрешением (resolving) имен могут возникнуть некоторые проблемы, например, имея сеть 192.168.0.0/16 служба DNS не сможет определить имя хоста с адресом 192.168.1.1, в результате произойдет подвисание команды. Чтобы обойти эту проблему следует выполнить вывод списка правил с дополнительным ключом:

iptables -L -n

Чтобы вывести дополнительную информацию о цепочках и правилах, выполните

iptables -L -n -v

Не забывайте о ключе -t, который может быть использован для просмотра таблиц nat и mangle, например:

iptables -L -t nat

В файловой системе /proc имеется ряд файлов, которые содержат достаточно интересную для нас информацию. Например, допустим нам захотелось просмотреть список соединений в таблице conntrack. Это основная таблица, которая содержит список трассируемых соединений и в каком состоянии каждое из них находится. Для просмотра таблицы выполните команду:

cat /proc/net/ip_conntrack | less

A.2. Изменение и очистка ваших таблиц¶

По мере того как вы продолжите углубляться в исследование iptables, перед вами все актуальнее будет вставать вопрос об удалении отдельных правил из цепочек без необходимости перезагрузки машины. Сейчас я попробую на него ответить. Если вы по ошибке добавили какое либо правило, то вам нужно только заменить команду -A на команду -D в строке правила. iptables найдет заданное правило и удалит его. Если имеется несколько правил, которые выглядят как заданный шаблон для удаления, то будет стерто первое из найденных правил. Если такой порядок вещей вас не устраивает, то команде -D, в качестве параметра, можно передать номер удаляемой строки, например, команда iptables -D INPUT 10 сотрет десятое правило в цепочке INPUT. (Чтобы узнать номер правила, подайте команду iptables -L НАЗВАНИЕ_ЦЕПОЧКИ —line-numbers, тогда правила будут выводиться со своими номерами прим. перев.)

Для удаления содержимого целой цепочки используйте команду -F. Например: iptables -F INPUT — сотрет все правила в цепочке INPUT, однако эта команда не изменяет политики цепочки по-умолчанию, так что если она установлена как DROP, то будет блокироваться все, что попадает в цепочку INPUT. Чтобы сбросить политику по-умолчанию, нужно просто установить ее в первоначальное состояние, например iptables -P INPUT ACCEPT. (И еще: если таблица не указана явно ключом -t (--table), то очистка цепочек производится ТОЛЬКО в таблице filter, прим. перев. )

Мною был написан небольшой сценарий (описанный несколько выше), который производит очистку всех таблиц и цепочек, и переустанавливает политики цепочек в iptables. Запомните, что при использовании таблицы mangle вам необходимо внести дополнения в этот сценарий, поскольку он ее не обрабатывает.

Приложение B. Общие проблемы и вопросы¶

B.1. Проблемы загрузки модулей¶

Вы можете столкнуться с несколькими проблемами при попытке загрузить тот или иной модуль. Например, может быть выдано сообщение об отсутствии запрашиваемого модуля

insmod: iptable_filter: no module by that name found

Пока еще нет причин для беспокойства. Вполне возможно, что запрашиваемый модуль (или модули) был связан с ядром статически. Это первое, что вы должны проверить. В примере, приведенном выше, произошла ошибка при загрузке таблицы filter. Чтобы проверить наличие этой таблицы просто запустите команду:

iptables -t filter -L

Если все нормально, то эта команда выведет список всех цепочек из таблицы filter. Вывод должен выглядеть примерно так:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Если таблица filter отсутствует, то вывод будет примерно следующим

iptables v1.2.5: can't initialize iptables table `filter': Table \
     does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Это уже серьезнее, так как это сообщение указывает на то, что либо вы забыли установить модули, либо вы забыли выполнить depmod -a, либо вы вообще не скомпилировали необходимые модули. Для решения первой проблемы запустите команду make modules_install в каталоге с исходными текстами ядра. Вторая проблема решается запуском команды depmod -a. Разрешение третьей проблемы уже выходит за рамки данного руководства, и в этом случае рекомендую посетить домашнюю страничку The Linux Documentation Project. (Взгляните еще раз в начало документа, где описывается процесс установки iptables. прим. перев.)

Другие ошибки, которые вы можете получить при запуске iptables:

iptables: No chain/target/match by that name

Эта ошибка сообщает, что нет такой цепочки, действия или критерия. Это может зависеть от огромного числа факторов, наиболее вероятно, что вы пытаетесь использовать несуществующую (или еще не определенную) цепочку, несуществующее действие или критерий. Либо потому, что не загружен необходимый модуль.

B.2. Пакеты со статусом NEW и со сброшенным битом SYN¶

Это свойство iptables недостаточно хорошо задокументировано, а поэтому многие могут уделить ему недостаточное внимание (включая и меня). Если вы используете правила, определяющие статус пакета NEW, но не проверяете состояние бита SYN, то пакеты со сброшенным битом SYN смогут «просочиться» через вашу защиту. Хотя, в случае, когда мы используем несколько брандмауэров, такой пакет может оказаться частью ESTABLISHED соединения, установленного через другой брандмауэр. Пропуская подобные пакеты, мы делаем возможным совместную работу двух или более брандмауэров, при этом мы можем любой из них остановить, не боясь разорвать установленные соединения, поскольку функции по передаче данных тут же возьмет на себя другой брандмауэр. Однако это позволит устанавливать практически любое TCP соединение. Во избежание этого следует добавить следующие правила в цепочки INPUT, OUTPUT и FORWARD:

$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG \
     --log-prefix "New not syn:" 
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Вышеприведенные правила позаботятся об этой проблеме. Будьте чрезвычайно внимательны при построении правил принимающих решение на основе статуса пакета.

Обратите внимание, что имеются некоторые неприятности с вышеприведенными правилами и плохой реализацией TCP/IP от Microsoft. Дело в том, что при некоторых условиях, пакеты, сгенерированные программами от Microsoft маркируются как NEW и согласно этим правилам будут сброшены. Это, однако, не приводит к разрушению соединений, насколько я знаю. Происходит это потому, что, когда соединение закрывается, и посылается завершающий пакет FIN/ACK, то netfilter закрывает это соединение и удаляет его из таблицы conntrack. В этот момент, дефектный код Microsoft посылает другой пакет, которому присваивается статус NEW, но в этом пакете не установлен бит SYN и, следовательно, соответствует вышеупомянутым правилам. Короче говоря — особо не переживайте по поводу этих правил. В случае чего — вы сможете просмотреть системный журнал, куда логируются отбрасываемые пакеты (см. правила выше) и разобраться с ними.

Имеется еще одна известная проблема с этими правилами. Если кто-то в настоящее время связан с брандмауэром, например из LAN, и активирует PPP, то в этом случае соединение будет уничтожено. Это происходит в момент, когда загружаются или выгружаются conntrack и nat модули. Другой способ получить эту проблему состоит в том, чтобы выполнить сценарий rc.firewall.txt из сеанса telnet с другого компьютера. Для этого вы соединяетесь по telnet с брандмауэром. Запускаете rc.firewall.txt, в процессе исполнения которого, запускаются модули трассировки подключений, грузятся правила "NEW not SYN". Когда клиент telnet или daemon пробуют послать что нибудь, то это подключение будет распознано трассировочным кодом как NEW, но пакеты не имеют установленного бита SYN, так как они, фактически, являются частью уже установленного соединения. Следовательно, пакет будет соответствовать правилам в результате чего будет зажурналирован и сброшен.

B.3. SYN/ACK — пакеты и пакеты со статусом NEW¶

Существует одна из разновидностей спуфинг-атак (от англ. spoofing — мистификация, подмена. прим. перев.), которая называется «Предсказание номера TCP-последовательности» (Sequence Number Prediction). Смысл атак такого рода заключается в использовании чужого IP-адреса для нападения на какой либо узел сети.

Для рассмотрения типичной Sequence Number Prediction атаки обозначим через [A] — атакующий хост, [V] — атакуемый хост, [O] — третий хост, чей IP-адрес используется атакующим.

Хост [A] отправляет SYN-пакет (запрос на соединение прим. перев.) хосту [V] с обратным IP-адресом хоста [O].
Хост [V] отвечает хосту [O] пакетом SYN/ACK.
Теперь, по логике вещей, хост [O] должен разорвать соединение пакетом RST, поскольку он не посылал запрос на соединение (пакет SYN) и попытка атаки провалится, однако, допустим, что хост [O] не ответил (оказался выключенным, перегружен работой или находится за брандмауэром, который не пропустил пакет SYN/ACK).
Если хост [O] не отправил пакет RST, прервав таким образом начавшуюся атаку, то атакующий хост [A] получает возможность взаимодействия с хостом [V], выдавая себя за [O].

Не передав RST-пакет, мы, тем самым, способствуем выполнению атаки на хост [V], которая может быть инкриминирована нам самим. Общепринятой считается необходимость отправления пакета RST в подобных случаях (RST в ответ на незапрошенный SYN/ACK). Если в вашем брандмауэре используются правила, фильтрующие пакеты со статусом NEW и сброшенным битом SYN, то SYN/ACK-пакеты будут «сбрасываться» этими правилами. Поэтому, следующее правило необходимо вставить в цепочку bad_tcp_packets первым:

iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset

В большинстве случаев подобные правила обеспечивают достаточный уровень безопасности для хоста [O] и риск от их использования относительно невелик. Исключение составляют случаи использования серии брандмауэров. В этом случае некоторые соединения могут оказаться заблокированными, даже если они вполне законны. Эти правила, ко всему прочему, допускают некоторые виды сканирования портов, но не более того.

B.4. Поставщики услуг Internet, использующие зарезервированные IP-адреса¶

Я добавил этот раздел чтобы предупредить вас о туповатых провайдерах (Internet Service Providers), которые назначают IP адреса, отведенные IANA для локальных сетей. Например, Swedish Internet Service Provider и телефонная монополия Telia используют такие адреса для своих серверов DNS (диапазон 10.x.x.x). Проблема, с которой вы будете наиболее вероятно сталкиваться, состоит в том, что мы, в своих сценариях, блокируем подключения с любых IP в диапазоне 10.x.x.x, из-за возможности фальсификации пакетов. Если вы столкнетесь с такой ситуацией, то наверное вам придется снять часть правил. Или установить правила, пропускающие траффик с этих серверов, ранее цепочки INPUT, например так:

/usr/local/sbin/iptables -t nat -I PREROUTING -i eth1 -s 10.0.0.1/32 -j ACCEPT

Хотелось бы напомнить подобным провайдерам, что эти диапазоны адресов не предназначены для использования в Интернет. Для корпоративных сетей — пожалуйста, для ваших собственных домашних сетей — прекрасно! Но вы не должны вынуждать нас «открываться» по вашей прихоти.

B.5. Как разрешить прохождение DHCP запросов через iptables¶

В действительности, эта задача достаточно проста, если вам известны принципы работы протокола DHCP. Прежде всего необходимо знать, что DHCP работает по протоколу UDP. Следовательно, протокол является первым критерием. Далее, необходимо уточнить интерфейс, например, если DHCP запросы идут через $LAN_IFACE, то движение запросов DHCP следует разрешить только через этот интерфейс. И наконец, чтобы сделать правило более определенным, следует уточнить порты. DHCP использует порты 67 и 68. Таким образом, искомое правило может выглядеть следующим образом:

$IPTABLES  -I INPUT -i $LAN_IFACE -p udp --dport 67:68 --sport 67:68 -j ACCEPT

Обратите внимание, это правило пропускает весь трафик по протоколу UDP через порты 67 и 68, однако это не должно вас особенно смущать, поскольку оно разрешает лишь движение запросов от узлов сети, пытающихся установить соединение с портами 67 и 68. Этого правила вполне достаточно, чтобы позволить выполнение DHCP запросов и при этом не слишком широко «открыть ворота». Если вас очень беспокоит проблема безопасности, то вы вполне можете ужесточить это правило.

B.6. Проблемы mIRC DCC¶

mIRC использует специфичные настройки, которые позволяют соединяться через брандмауэр и обрабатывать DCC соединения должным образом. Если эти настройки используются совместно с iptables, точнее с модулями ip_conntrack_irc и ip_nat_irc, то эта связка просто не будет работать. Проблема заключается в том, что mIRC автоматически выполняет трансляцию сетевых адресов (NAT) внутри пакетов. В результате, когда пакет попадает в iptables, она просто не знает, что с ним делать. mIRC не ожидает, что брандмауэр будет настолько «умным», чтобы корректно обрабатывать IRC, и поэтому самостоятельно запрашивает свой IP у сервера и затем подставляет его, при передаче DCC запроса.

Включение опции «I am behind a firewall» («Я за брандмауэром») и использование модулей ip_conntrack_irc и ip_nat_irc приводит к тому, что netfilter пишет в системный журнал сообщение "Forged DCC send packet".

У этой проблемы есть простое решение — отключите эту опцию в mIRC и позвольте iptables выполнять всю работу.

Приложение C. Типы ICMP¶

Это полный список типов ICMP сообщений:

Таблица C-1. ICMP types

ТИП	КОД	Описание	Запрос	Ошибка
0	0	Echo Reply	x
3	0	Network Unreachable		x
3	1	Host Unreachable		x
3	2	Protocol Unreachable		x
3	3	Port Unreachable		x
3	4	Fragmentation needed but no frag. bit set		x
3	5	Source routing failed		x
3	6	Destination network unknown		x
3	7	Destination host unknown		x
3	8	Source host isolated (obsolete)		x
3	9	Destination network administratively prohibited		x
3	10	Destination host administratively prohibited		x
3	11	Network unreachable for TOS		x
3	12	Host unreachable for TOS		x
3	13	Communication administratively prohibited by filtering		x
3	14	Host precedence violation		x
3	15	Precedence cutoff in effect		x
4	0	Source quench
5	0	Redirect for network
5	1	Redirect for host
5	2	Redirect for TOS and network
5	3	Redirect for TOS and host
8	0	Echo request	x
9	0	Router advertisement
10	0	Route solicitation
11	0	TTL equals 0 during transit		x
11	1	TTL equals 0 during reassembly		x
12	0	IP header bad (catchall error)		x
12	1	Required options missing		x
13	0	Timestamp request (obsolete)	x
14		Timestamp reply (obsolete)	x
15	0	Information request (obsolete)	x
16	0	Information reply (obsolete)	x
17	0	Address mask request	x
18	0	Address mask reply	x

Приложение D. Ссылки на другие ресурсы¶

Здесь приведен список ссылок, где вы сможете получить дополнительную информацию :

ip-sysctl.txt — из документации к ядру 2.4.14. Маленький, но хороший справочник по организации сетевого кода ядра.
ip_dynaddr.txt — из документации к ядру 2.4.14. Маленький справочник по параметрам настройки ip_dynaddr, доступным через sysctl и файловую систему /proc.
iptables.8 — Маны для iptables 1.2.4 в формате HTML Прекрасное руководство для создания правил в iptables. Всегда полезно иметь под рукой.
The Internet Control Message Protocol — Хороший и подробный документ, описывающийпротокол ICMP. Написан Ральфом Уолденом (Ralph Walden).
RFC 792 — Internet Control Message Protocol — Официальный источник информации по протоколу ICMP. Содержит всю техническую информацию о протоколе ICMP, которая только может потребоваться. Автор J. Postel.
RFC 793 — Transmission Control Protocol — Этот документ описывает стандарт протокола TCP. Документ чрезвычайно насыщен техническими подробностями, однако всякий, желающий понять работу протокола TCP во всех деталях, должен прочитать этот документ. Автор J. Postel.
http://www.netfilter.org/ — Официальный сайт netfilter и iptables. Необходим для всех желающих установить iptables и netfilter в linux.
Firewall rules table — Небольшой файл в формате PDF, любезно предоставленный Стюартом Кларком (Stuart Clark), который представляет из себя набор бланков для ведения отчетности по правилам, используемым на брандмауэре.
/etc/protocols — Пример файла protocols, полученный в дистрибутиве Slackware. Может служить справочником по номерам протоколов, таких как IP, ICMP или TCP.
/etc/services — Пример файла services, полученный в дистрибутиве Slackware. Чрезвычайно полезен для просмотра, чтобы увидеть какие протоколы с какими портами работают.
Internet Engineering Task Force — Одна из самых больших групп, которые занимаются установлением и поддержкой стандартов Internet. Поддерживает свой репозиторий RFC. Включает в себя как крупные компании, так и отделные лица, с целью обеспечения межоперабельности Интернета.
Linux Advanced Routing and Traffic Control HOW-TO — Один из лучших документов, касающихся роутинга. Поддерживается сайт Бертом Хубертом (Bert Hubert).
Paksecured Linux Kernel patches — На сайте вы найдете все «заплаты» к ядру, написанные Matthew G. Marsh. Среди всего прочего, здесь вы найдете «заплату» FTOS.
ULOGD project page — Домашняя страница проекта ULOGD.
The Linux Documentation Project один из лучших сайтов, содержащих документацию. Здесь вы найдете огромное количество документов по Linux-тематике.
http://www.netfilter.org/documentation/index.html#FAQ — Официальный FAQ (Frequently Asked Questions) по netfilter .
http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html — Rusty Russells Unreliable Guide to packet filtering. Прекрасная документация по основам фильтрации пакетов с помощью iptables, написанная одним из разработчиков iptables и netfilter.
http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html — Rusty Russells Unreliable Guide to Network Address Translation. Замечательная документация по Network Address Translation в iptables и netfilter, написанная одним из основных разработчиков Расти Расселом (Rusty Russell).
http://netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO.html — Rusty Russells Unreliable Netfilter Hacking HOWTO. Один из немногих документов по созданию кода для работы с netfilter и iptables. Так же написан Расти Расселом (Rusty Russell).
http://www.linuxguruz.org/iptables/ — Содержит множество ссылок в Интернет по тематике. Имеется список сценариев iptables для различных применений.
http://www.faqs.org/docs/gazette/firewalls.html — Отличное обсуждение по автоматизации работы iptables, например: как, внесением незначительных изменений, заставить ваш компьютер автоматически добавлять «неугодные» сайты в специальный список (banlist) в iptables.
http://www.rigacci.org/wiki/lib/exe/fetch.php/doc/appunti/linux/sa/iptables/conntrack.html — Прекрасное описание модулей трассировщика соединений. Если вам интересна тема трассировки соединений, то вам следует это прочитать.
http://www.docum.org — Один из немногих сайтов, который содержит информацию о командах Linux CBQ, tc и ip. Поддерживает сайт — Stef Coene.
http://lists.samba.org/mailman/listinfo/netfilter — Официальный список адресов (mailing-list) по netfilter. Чрезвычайно полезен для разрешения вопросов по iptables и netfilter.

И конечно же, исходный код iptables, документация и люди, которые помогали мне.

Приложение E. Благодарности¶

Автор: Oskar Andreasson

Перевод: Андрей Киселев (kis_an@mail.ru)

Источник

http://ru.wikibooks.org/wiki/Iptables

iptables — утилита интерфейс командной строки, является стандартным интерфейсом управления работой межсетевого экрана (брандмауэра) netfilter для ядер Linux версий 2.4 и 2.6. Для использования утилиты iptables требуются привилегии суперпользователя (root).

Иногда под словом iptables имеется в виду и сам межсетевой экран netfilter.

История

Изначально разработка netfilter и iptables шла совместно, поэтому в ранней истории этих проектов есть много общего. Подробности см. в статье про netfilter.

Предшественниками iptables были проекты ipchains (применялась для администрирования фаервола ядра Linux версии 2.2) и ipfwadm (аналогично для ядер Linux версий 2.0). Последний был основан на BSD-утилите ipfw.

iptables сохраняет идеологию, ведущую начало от ipfwadm: функционирование фаервола определяется набором правил, каждое из которых состоит из критерия и действия, применяемого к пакетам, подпадающим под этот критерий. В ipchains появилась концепция цепочек — независимых списков правил. Были введены отдельные цепочки для фильтрации входящих (INPUT), исходящих (OUTPUT) и транзитных (FORWARD) пакетов. В продолжении этой идеи, в iptables появились таблицы — независимые группы цепочек. Каждая таблица решала свою задачу — цепочки таблицы filter отвечали за фильтрацию, цепочки таблицы nat — за преобразование сетевых адресов (NAT), к задачам таблицы mangle относились прочие модификации заголовков пакетов (например, изменение TTL или TOS). Кроме того, была слегка изменена логика работы цепочек: в ipchains все входящие пакеты, включая транзитные, проходили цепочку INPUT. В iptables через INPUT проходят только пакеты, адресованные самому хосту.

Такое разделение функциональности позволило iptables при обработке отдельных пакетов использовать информацию о соединениях в целом (ранее это было возможно только для NAT). В этом iptables значительно превосходит ipchains, так iptables может отслеживать состояние соединения и перенаправлять, изменять или отфильтровывать пакеты, основываясь не только на данных из их заголовков (источник, получатель) или содержимом пакетов, но и на основании данных о соединении. Такая возможность фаервола называется stateful-фильтрацией, в отличие от реализованной в ipchains примитивной stateless-фильтрации (подробнее о видах фильтрации см. статью о фаерволах). Можно сказать, что iptables анализирует не только передаваемые данные, но и контекст их передачи, в отличие от ipchains, и поэтому может принимать более обоснованные решения о судьбе каждого конкретного пакета. Более подробно о stateful-фильтрации в netfilter/iptables см. Netfilter#Механизм определения состояний.

В будущем, разработчики netfilter планируют заменить iptables на nftables — инструмент нового поколения, пока находящийся в ранней стадии разработки^[1].

Архитектура

Основные понятия

Ключевыми понятиями iptables являются:

Правило — состоит из критерия, действия и счетчика. Если пакет соответствует критерию, к нему применяется действие, и он учитывается счетчиком. Критерия может и не быть — тогда неявно предполагается критерий «все пакеты». Указывать действие тоже не обязательно — в отсутствие действия правило будет работать только как счетчик.
- Критерий — логическое выражение, анализирующее свойства пакета и/или соединения и определяющее, подпадает ли данный конкретный пакет под действие текущего правила.
- Действие — описание действия, которое нужно проделать с пакетом и/или соединением в том случае, если они подпадают под действие этого правила. О действиях более подробно будет рассказано ниже.
- Счетчик — компонент правила, обеспечивающий учет количества пакетов, которые попали под критерий данного правила. Также счетчик учитывает суммарный объем таких пакетов в байтах.

Цепочка — упорядоченная последовательность правил. Цепочки можно разделить на пользовательские и базовые.
- Базовая цепочка — цепочка, создаваемая по умолчанию при инициализации таблицы. Каждый пакет, в зависимости от того, предназначен ли он самому хосту, сгенерирован им или является транзитным, должен пройти положенный ему набор базовых цепочек различных таблиц. Схема следования пакетов приведена на рисунке. Кроме того, базовая цепочка отличается от пользовательской наличием «действия по умолчанию» (default policy). Это действие применяется к тем пакетам, которые не были обработаны другими правилами этой цепочки и вызванных из нее цепочек (см. переходы). Имена базовых цепочек всегда записываются в верхнем регистре (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING).
- Пользовательская цепочка — цепочка, созданная пользователем. Может использоваться только в пределах своей таблицы. Рекомендуется не использовать для таких цепочек имена в верхнем регистре, чтобы избежать путаницы с базовыми цепочками и встроенными действиями.
Таблица — совокупность базовых и пользовательских цепочек, объединенных общим функциональным назначением. Имена таблиц (как и модулей критериев) записываются в нижнем регистре, так как в принципе не могут конфликтовать с именами пользовательских цепочек. При вызове команды iptables таблица указывается в формате -t имя_таблицы. При отсутствии явного указания, используется таблица filter. Более подробно таблицы будут рассмотрены ниже.

Принцип работы

Все пакеты пропускаются через определенные для них последовательности цепочек (см. рис.). При прохождении пакетом цепочки, к нему последовательно применяются все правила этой цепочки в порядке их следования. Под применением правила понимается: во-первых, проверка пакета на соответствие критерию, и во-вторых, если пакет этому критерию соответствует, применение к нему указанного действия. Под действием может подразумеваться как элементарная операция (встроенное действие, например, ACCEPT, MARK), так и переход в одну из пользовательских цепочек. В свою очередь, действия могут быть как терминальными, то есть прекращающими обработку пакета в рамках данной базовой цепочки (например, ACCEPT, REJECT), так и нетерминальными, то есть не прерывающими процесса обработки пакета (MARK, TOS). Если пакет прошел через всю базовую цепочку и к нему так и не было применено ни одного терминального действия, к нему применяется действие по умолчанию для данной цепочки (обязательно терминальное). Например,

iptables -F # Очищаем все цепочки таблицы filter
# Ко всем пакетам, которые относятся к уже установленным соединениям, применяем терминальное действие ACCEPT — пропустить
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -P INPUT DROP # В качестве действия по умолчанию устанавливаем DROP — блокирование пакета
iptables -P OUTPUT ACCEPT # Разрешаем все исходящие пакеты

Теперь цепочка INPUT таблицы filter содержит единственное правило, которое пропускает все пакеты, относящиеся к уже установленным соединениям. Ко всем остальным входящим пакетам будет применено действие по умолчанию — DROP. Цепочка же OUTPUT вообще не содержит правил, поэтому ко всем исходящим пакетам будет применяться действие по умолчанию ACCEPT. Таким образом хост, настроенный согласно этому примеру и подключенный к Интернету, будет недоступен извне (все попытки установить соединение снаружи блокируются), однако с самого хоста доступ к Интернету будет свободный (исходящие пакеты разрешены, а ответы на них уже относятся к установленным соединениям).

Основные компоненты

netfilter

Компонент ядра Linux, обеспечивающий фильтрацию и модификацию трафика. Собственно, именно он и является фаерволом. В состав netfilter входят следующие модули:

ip_tables — фаервол для протокола IPv4. Обеспечивает фильтрацию пакетов, модификацию их заголовков и трансляцию сетевых адресов.
ip6_tables — фаервол для протокола IPv6. Обеспечивает фильтрацию пакетов и модификацию их заголовков.
arp_tables — фаервол для протоколов ARP и RARP. Обеспечивает фильтрацию и модификацию пакетов.
x_tables — бэкенд для ip_tables, ip6_tables и arp_tables. В этом модуле определены основные операции для работы с фаерволами «таблично-цепочечной» структуры и их компонентами.
ebtables — Ethernet-фаервол (префикс eb от Ethernet Bridge). В отличие от трех перечисленных выше фаерволов, работающих с протоколами сетевого и более высоких уровней, ebtables работает на канальном уровне, выполняя фильтрацию и модификацию ethernet-кадров, проходящих через сетевые мосты, если таковые имеются на хосте.

Принципы работы с ip_tables и ip6_tables практически идентичны, с тем небольшим отличием, что в ip6_tables отсутствует таблица nat и соответствующие действия. В то же время, принципы построения правил в arp_tables и ebtables несколько иные. В частности, arp_tables и ebtables имеют четыре базовых действия — ACCEPT (пропустить), DROP (заблокировать), CONTINUE (продолжить обработку в данной цепочке) и RETURN (прекратить обработку в данной цепочке, вернуть в цепочку уровнем выше). Эти действия могут использоваться отдельно, либо применяться к пакетам после выполнения какой-либо преобразующего действия (например, маркировки). Таким образом, после применения преобразования пакет может быть, скажем, немедленно пропущен фаерволом (ACCEPT), либо будет вынужден проследовать через последующие правила (CONTINUE). Этим arptables и ebtables отличаются от ip_tables и ip6_tables — в последних существует четкое разделение действий на терминальные и нетерминальные, которое нельзя изменить при составлении набора правил, а чтобы, например, пропустить пакет после некоторого нетерминального преобразования, необходимо добавлять дополнительное правило («iptables … -j MARK …; iptables … -j ACCEPT» вместо «ebtables … -j mark … —mark-target ACCEPT»). Также, система conntrack не производит отслеживание соединений для ARP/RARP и Ethernet, поэтому возможности stateful-фильтрации в arp_tables и ebtables отсутствуют (нет критерия conntrack и таблицы raw).

В данной статье рассматриваются только аспекты работы с ip_tables и ip6_tables. В их задачи входит:

Классификация пакетов на основе различных критериев. В качестве критерия могут выступать, например, IP-адреса источника и/или назначения, состояние соединения (новое/уже установленное), порты источника и/или назначения (для протоколов транспортного уровня, имеющих порты), вспомогательные значения в заголовках пакетов (скажем, длина пакета, TOS, TTL) и т. п. Результаты этой классификации используются при решении других задач из данного списка.
Фильтрация входящих (INPUT), исходящих (OUTPUT) и транзитных (FORWARD) пакетов, сводящуюся либо к их пропусканию (ACCEPT), либо к блокированию (DROP или REJECT). Также поддерживаются дополнительные возможности, например, блокирование попыток сканирования портов (DELUDE и CHAOS), эффективное противодействие (D)DoS-атакам (TARPIT).
Модификация заголовков пакетов и связанной информации. К этому классу задач можно отнести:
- Трансляцию сетевых адресов (NAT), включая маскарадинг (SNAT или MASQUERADE), «проброс» адресов и портов (DNAT) и даже целых подсетей (NETMAP). Эта задача касается только модуля ip_tables. Модуль ip6_tables не производит трансляции адресов.
- Изменение различных вспомогательных величин в заголовках пакетов, например, TOS, TTL, TCP MSS.
- Установку и изменение маркировки пакетов и соединений. Впоследствии эта маркировка может быть использована системой iproute2 для маршрутизации и шейпинга трафика.
Учет количества обработанных пакетов и их суммарного размера при помощи счетчиков.
Занесение информации о пакетах в системный журнал (LOG и LOGMARK).
Передача на обработку userspace-демонам пакетов целиком (NFQUEUE) либо информации о них (NFLOG), что позволяет решать самый широкий круг задач по фильтрации, модификации и учету трафика.
Внутренние задачи, связанные с обеспечением работы критериев и действий netfilter. Например, сопровождение списков IP-адресов для критериев recent и hashlimit.

iptables

Userspace-утилита, через которую системный администратор может управлять IPv4-фаерволом (ip_tables). К ее задачам относятся:

Создание и удаление пользовательских цепочек.
Установка действий по умолчанию для базовых цепочек.
Добавление и удаление правил.
Установка и обнуление счетчиков пакетов и байт.
Вывод цепочек и правил, а также значений счетчиков.
Проверка корректности задания параметров, определяющих работу критериев и действий.
Вывод справки по использованию критериев (iptables -m критерий -h) и действий (iptables -j действие -h).

Также в комплект поставки вместе с iptables обычно входят вспомогательные утилиты, обеспечивающие сохранение (iptables-save) и последующее восстановление (iptables-restore) состояния фаервола, его инициализацию при запуске системы (init-скрипт) и т. п.

Сегментом фаервола, отвечающим за фильтрацию IPv6-пакетов (ip6_tables), управляет утилита ip6tables. Так как обычно она поставляется вместе с iptables, имеет похожий синтаксис и выполняет схожие задачи, под термином «iptables» часто подразумевают сразу обе эти утилиты.

Также в рамках данного проекта разрабатываются два набора библиотек:

libiptc — содержит функции, осуществляющие вышеперечисленные операции по управлению цепочками и правилами. Именно с этими функциями и работают утилиты iptables (библиотека libip4tc) и ip6tables (библиотека libip6tc). Приложения, использующие эти библиотеки, могут обращаться к netfilter напрямую, минуя вызов утилит iptables и ip6tables. В качестве примера такого приложения можно назвать Perl-модуль IPTables::libiptc, предоставляющий доступ к функциям этих библиотек из Perl-скриптов.
libipq — содержит функции, позволяющие пользовательским приложениям принимать IP-пакеты на обработку. Отправка со стороны ядра выполняется через модуль ip_queue (ip6_queue для IPv6), что соответствует действию QUEUE. В настоящее время этот механизм объявлен устаревшим, и вместо него рекомендуется использовать действие NFQUEUE, работа которого реализуется через модуль ядра nfnetlink_queue и библиотеку libnetfilter_queue.

conntrack

Компонент netfilter, обеспечивающий отслеживание состояния соединений и классификацию пакетов с точки зрения принадлежности к соединениям, что позволяет netfilter осуществлять полноценную stateful-фильтрацию трафика. Как и netfilter, система conntrack является частью ядра Linux. К ее задачам относятся:

Отслеживание состояний отдельных соединений с тем, чтобы классифицировать каждый пакет либо как относящийся к уже установленному соединению, либо как открывающий новое соединение. При этом понятие «состояние соединения» искусственно вводится для протоколов, в которых оно изначально отсутствует (UDP, ICMP). При работе же с протоколами, поддерживающими состояния (например, TCP), conntrack активно использует эту возможность, тесно взаимодействуя с базовой сетевой подсистемой ядра Linux.
Отслеживание связанных соединений, например, ICMP-ответов на TCP и UDP-пакеты. Более сложный вариант — протоколы, использующие несколько соединений в одной сессии, например, FTP. Для правильной обработки таких протоколов conntrack использует специальные модули (conntrack helpers), которые анализируют трафик и «выхватывают» информацию протокола о новых соединениях (например, порт, на который оно будет открыто), что позволяет обеспечить их корректную фильтрацию, маршрутизацию, шейпинг и пропускание через NAT.

Более подробно о возможностях системы conntrack и их использовании при работе с iptables/netfilter см. чуть ниже.

В состав conntrack входят следующие компоненты:

Главный модуль nf_conntrack. Реализует базовую функциональность отслеживания соединений, интерфейсы для работы с модулями расширений, а также механизмы отслеживания протоколов TCP и UDP.
Трекеры протоколов сетевого уровня: nf_conntrack_ipv4 и nf_conntrack_ipv6. Реализуют операции, специфичные для «своих» протоколов (IPv4 и IPv6 соответственно), а также механизмы отслеживания соответствующих протоколов управляющих сообщений (ICMP и ICMPv6 соответственно).
Трекеры протоколов транспортного уровня (кроме TCP и UDP, реализованных в главном модуле): nf_conntrack_proto_sctp (SCTP), nf_conntrack_proto_dccp (DCCP), nf_conntrack_proto_gre (GRE), nf_conntrack_proto_udplite (UDP Lite).
Вспомогательные модули (helpers), обеспечивающие отслеживание протоколов прикладного и сеансового уровней: nf_conntrack_ftp, nf_conntrack_irc, nf_conntrack_pptp, nf_conntrack_netbios_ns и т. п. Требуются далеко не для всех протоколов, а только для тех, отслеживание которых требует знания специфики протокола. Например, неоднократно упоминающийся в этой статье протокол FTP использует в одном сеансе два соединения (управляющее соединение и соединение передачи данных), и чтобы корректно отследить соединение передачи данных, необходимо анализировать трафик управляющего соединения и выделять в нем информацию, касающуюся открытия соединения данных.
Модуль nf_nat. Реализует базовую функциональность трансляции сетевых адресов и портов с учетом информации о соединениях. Также этот модуль содержит механизмы трансляции для протоколов IPv4, TCP, UDP и ICMP (IPv6 и ICMPv6 не поддерживаются NAT-подсистемой conntrack).
NAT-трекеры протоколов транспортного уровня: nf_nat_proto_sctp, nf_nat_proto_dccp, nf_nat_proto_gre, nf_nat_proto_udplite.
Вспомогательные модули NAT для протоколов прикладного и сеансового уровней: nf_nat_ftp, nf_nat_irc, nf_nat_pptp и т. п.
Модуль взаимодействия с userspace через протокол nfnetlink (см. следующий раздел) nf_conntrack_netlink, которому соответствует userspace-библиотека libnetfilter_conntrack.
Кроме того, к conntrack можно условно отнести и модули netfilter, обеспечивающие взаимодействие этих двух подсистем: критерий conntrack (xt_conntrack), действия NOTRACK и CT (xt_NOTRACK и xt_CT), практически все действия таблицы nat, а также соответствующие модули (библиотеки iptables/ip6tables): libxt_conntrack, libxt_NOTRACK, libxt_CT и т. п.

Для взаимодействия с системой conntrack из userspace разработан комплект conntrack-tools, содержащий две утилиты:

conntrack — инструмент, позволяющий системному администратору наблюдать таблицы состояний соединений и взаимодействовать с ними: очищать таблицы целиком, удалять отдельные записи, маркировать соединения вручную (аналог действия CONNMARK), устанавливать тайм-ауты соединений. Поддерживается фильтрация вывода (например, на основании адресов и/или портов источника и/или назначения), а также вывод в различных форматах, включая XML. Кроме того, данная утилита позволяет отслеживать в реальном времени события системы conntrack, например, открытие новых соединений или изменение состояния существующих.
conntrackd — демон, обеспечивающий синхронизацию таблиц состояний с другими хостами, что в сочетании с возможностями демона keepalived позволяет создавать фаерволы на кластерах высокой доступности (High Availability) — при выходе из строя одного из хостов кластера его соединения будут «подхвачены» другими хостами кластера и корректно обработаны с учетом состояний. Также conntrackd можно использовать просто для удаленного сбора статистики по соединениям.

Взаимодействие conntrack с этими программами производится посредством интерфейса nfnetlink, который будет рассмотрен в следующем разделе.

nfnetlink

Интерфейс, позволяющий различным userspace-приложениям взаимодействовать с netfilter и conntrack. Со стороны userspace он обеспечивается набором библиотек libnfnetlink. Ключевые библиотеки из этого набора:

libnetfilter_conntrack (ранее libnfnetlink_conntrack и libctnetlink) — обеспечивает взаимодействие приложений с системой conntrack. В качестве примеров приложений, использующих эту библиотеку, можно упомянуть:
- Описанные выше программы conntrack и conntrackd из комплекта conntrack-tools.
- iptstate — в какой-то мере аналог утилиты conntrack, хотя и не имеющий таких богатых возможностей. Предназначена для непрерывного вывода таблицы состояний соединений с периодическим обновлением, в стиле широко известной утилиты top. Поддерживает различные виды сортировки (по адресам/портам источника/назначения, тайм-ауту, счетчикам и т. п.). Позволяет удалять записи из таблицы состояний. Не поддерживает работу с таблицей ожидаемых (expected) соединений.
libnetfilter_queue (ранее libnfnetlink_queue) — отвечает за передачу пакетов демонам на предмет анализа. По результатам этого анализа пакет может быть заблокирован или пропущен. При пропускании пакета возможна установка или изменение его маркировки (nfmark). Идеологическим предшественником libnetfilter_queue была ныне устаревшая библиотека libipq. В качестве примеров приложений, использующих libnetfilter_queue, можно упомянуть:
- nufw — фаервол, выполняющий фильтрацию трафика на основе авторизации пользователей. Позволяет устанавливать ограничения на доступ к сетям, находящимся за фаерволом, для отдельных пользователей. Авторизация пользователей на фаерволе обеспечивается отдельным демоном nuauth. Например, в случае, если клиенты используют Linux, авторизация может выполняться совершенно прозрачно, благодаря возможностям PAM (модуль pam_nufw) в момент входа пользователя в систему. Особенно удобны подобные системы в корпоративных сетях, где используются системы централизованного управления аккаунтами пользователей (nufw/nuauth поддерживает LDAP и winbind).
- l7-filter-userspace — демон, позволяющий определить протокол 7-го (прикладного) уровня модели OSI, которому принадлежит полученный пакет, на основании анализа его содержимого при помощи регулярных выражений. Результат анализа возвращает в маркировке пакета. Полезен при фильтрации и шейпинге трафика протоколов, не имеющих фиксированных номеров портов для соединений данных, например, BitTorrent. Впрочем, в настоящее время существуют и альтернативные решения — P2P-протоколы можно выделять при помощи критерия ipp2p (из набора xtables-addons), а вспомогательные соединения в известных системе conntrack протоколах (FTP, IRC, SIP) можно выделять при помощи критерия helper и маркировки соединений.
- iplist — userspace-альтернатива ipset. Как и ipset, позволяет считывать большие списки IP-адресов и проверять пакеты на предмет нахождения адреса их источника/назначения в данном списке. В зависимости от результата проверки, пакет может быть пропущен или заблокирован, либо промаркирован соответствующим образом. Разумеется, ipset, работая на уровне ядра, обеспечивает более высокую скорость проверки, а также поддерживает дополнительные возможности, например, динамическое изменение списков при помощи действия SET (добавление и удаление записей), сохранение дополнительной информации (номера портов, MAC-адреса, тайм-ауты записей). Несмотря на то, что в настоящий момент ipset пока что не принят в ядро, современные дистрибутивы ipset позволяет произвести сборку и установку необходимых компонентов без необходимости наложения патчей на ядро и iptables, благодаря возможностям подгружаемых модулей (en:LKM) ядра Linux. Поэтому, с учетом вышесказанного, необходимость в iplist в настоящее время сомнительна.
libnetfilter_log (ранее libnfnetlink_log) — предоставляет демонам интерфейс для получения служебной информации о пакетах на предмет регистрации и учета трафика. В настоящее время известен только один проект, использующий данную библиотеку — ulogd2 ([netfilter] userspace logging daemon, версия 2). Данный проект находится пока в бета-стадии разработки. Надо заметить, что ulogd2 может получать информацию не только через libnetfilter_log (действие NFLOG), но и через классический механизм libipulog (действие ULOG), а также через libnetfilter_conntrack (данный метод позволяет получать информацию не об отдельных пакетах, а о соединениях в целом).

Со стороны ядра взаимодействие обеспечивается базовым модулем nfnetlink и «специализированными» модулями nf_conntrack_netlink, nfnetlink_queue и nfnetlink_log соответственно.

Кроме того, такие программы, как nfnl_osf (передает ядру список сигнатур для критерия детекции операционной системы osf) и ipset начиная с версии 5 (см. ниже) также используют для коммуникаций ядро-userspace интерфейс nfnetlink, но эти задачи являются узкоспециализированными и поэтому реализованы без использования специальных библиотек и модулей ядра.

ipset

Представляет собой набор инструментов, позволяющий работать с большими списками (sets) IP-адресов и/или портов. Поддерживается возможность динамического обновления списков при прохождении пакетов через правила netfilter.

В версии ipset 4 и более ранних поддерживалась работа только с семейством адресов IPv4, однако начиная с пятой версии реализована также и поддержка IPv6.

Стоит отметить, что долгое время проект ipset существовал вне основной ветки развития ядра Linux. В частности, в четвертой версии ipset «ядерные» компоненты приходилось собирать отдельно, используя заголовочные файлы текущего ядра. Однако, после выхода пятой версии, в которой были учтены все предыдущие замечания, началась работа по включению ipset в основную ветку. Она завершилась успехом: поддержка ipset присутствует в Linux начиная с 2.6.39. В ходе этих работ протокол взаимодействия ядерной и userspace-частей ipset подвергся значительной переработке, и окончательная версия получила номер 6.0. Таким образом, в современных ядрах поддержка ipset присутствует штатно, а пользователи более старых ядер могут воспользоваться реализациями ipset версий 4 и 5, включенными в набор xtables-addons.

ipset состоит из следующих элементов:

Модуль ядра ip_set, обеспечивающий базовый инструментарий работы со списками записей, который используется модулями расширений.
Модули расширений, определяющие конкретные структуры записей и методы работы с ними, например, ip_set_hash_ip (тип данных hash:ip), ip_set_bitmap_port (тип данных bitmap:port) и т. д.
Userspace-утилита ipset, позволяющая выполнять различные операции со списками и записями в них:
- Создание, удаление, переименование, вывод, очистка списков.
- Добавление и удаление записей из списков, проверка наличия записи в списке.
- Вывод справочной информации по работе со списками различного типа.
Модули расширений для утилиты ipset, соответствующие модулям расширений в ядре, например, ipset_hash_ip (тип данных hash:ip), ipset_bitmap_port (тип данных bitmap:port) и т. д. Каждый такой модуль отвечает за обеспечение интерфейса между «своим» модулем ядра и конечным пользователем, в частности, проверку корректности вводимых и форматирование выводимых данных, а также вывод справочной информации по допустимым командам и параметрам. В ранних версиях ipset (до 4 включительно) такие модули выделялись в виде подгружаемых библиотек, однако в современных версиях ipset они статически включаются в основной бинарник, поэтому разделение существует лишь в исходном коде.
Модуль netfilter xt_set (критерий set и действие SET), а также соответствующие модули (библиотеки) iptables (libxt_set и libxt_SET). Критерий set позволяет проверять различные параметры пакета (IP/MAC-адреса, TCP/UDP-порты источника и/или получателя) на предмет нахождения или отсутствия в списке. Действие SET позволяет добавлять или удалять записи из списка на основании указанных параметров пакета.

ipset поддерживает следующие типы данных (в скобках приведены названия согласно терминологии устаревшей версии ipset 4):

bitmap:ip (ipmap) — полный перечень IP-адресов.
bitmap:ip,mac (macipmap) — полный перечень IP-адресов, причем вместе с каждым IP-адресом может быть сохранен MAC-адрес.
bitmap:port (portmap) — полный перечень портов.
hash:ip (iphash) — выборочный перечень IP-адресов (либо IP-подсетей с одинаковой маской).
hash:net (nethash) — выборочный перечень IP-подсетей (блоков IP-адресов). В отличие от hash:ip, в одном списке могут присутствовать подсети с различными масками.
hash:ip,port (ipporthash) — выборочный перечень IP-адресов, причем с каждым адресом может быть сохранен порт. В версии ipset 4 и более ранних существует ограничение: адреса в пределах одного перечня должны принадлежать одному блоку /16 (/255.255.0.0, максимум 65536 адресов). Начиная с версии ipset 5, для каждого номера порта можно также сохранять идентификатор протокола транспортного уровня.
hash:ip,port,ip (ipportiphash) — выборочный перечень IP-адресов, причем с каждым адресом может быть сохранен порт и еще один IP-адрес. В версии ipset 4 и более ранних ограничение на «первичные» адреса (первые в тройке адрес-порт-адрес) такое же, как и для ipporthash. Начиная с версии ipset 5, для каждого номера порта можно также сохранять идентификатор протокола транспортного уровня.
hash:ip,port,net (ipportnethash) — выборочный перечень IP-адресов, причем с каждым адресом может быть сохранен порт и IP-подсеть. В версии ipset 4 и более ранних ограничение на «первичные» адреса такое же, как и у типа ipporthash. Начиная с версии ipset 5, для каждого номера порта можно также сохранять идентификатор протокола транспортного уровня.
list:set (setlist) — список списков. Может содержать списки любого перечисленного здесь типа, кроме list:set. При обращении к такому объекту из netfilter, включенные в него списки рассматриваются как один большой список. Поиск записей (критерий set) производится по всем вложенным спискам соответствующего типа. При добавлении записей (действие SET), вложенные списки поочередно проверяются (согласно порядку их перечисления) на соответствие типа и наличие свободного места, и запись добавляется в первый же подходящий. В то же время, при обращении к такому списку через утилиту ipset, он рассматривается именно как совокупность элементов-списков, что позволяет добавлять, удалять и проверять наличие именно вложенных списков, но не их элементов.
hash:net,iface — выборочный перечень IP-подсетей, причем с каждой подсетью может быть сохранено название сетевого интерфейса. Появился в версии ipset 6.7 (входит в Linux 3.1), ранние версии ipset не имеют подобных возможностей. Существует ограничение: нельзя сохранять более 64 имен интерфейсов с одним и тем же адресом подсети. Этот тип данных удобен при наличии в системе большого количества сетевых интерфейсов (например, сотен VLAN-интерфейсов).

В четвертой версии дополнительно присутствовали два типа списков, упраздненные в более поздних версиях:

iptree — выборочный перечень IP-адресов, причем с каждым адресом может быть сохранено значение тайм-аута в секундах. По истечении тайм-аута адрес удаляется из списка. Чтобы активировать возможность использование тайм-аутов для определенного списка, нужно при его создании задать тайм-аут по умолчанию (опция —timeout). Начиная с версии ipset 5, данный тип не поддерживается, при попытке его использования автоматически заменяется на hash:ip. Заметим, что начиная с пятой версии тайм-ауты реализованы для всех поддерживаемых типов данных.
iptreemap — гибридный перечень, позволяющий сохранять адреса, блоки и диапазоны адресов. Начиная с версии ipset 5, данный тип не поддерживается, при попытке его использования автоматически заменяется на hash:ip. Стоит отметить, что в современных версиях ipset при работе с адресами IPv4 можно указывать диапазоны адресов и подсети, которые при обращении к внутренним спискам будут автоматически преобразованы в наборы соответствующих элементов, Например, ipset create foo hash:ip; ipset add foo 192.168.0.0-192.168.0.3 добавит в список foo адреса 192.168.0.0, 192.168.0.1, 192.168.0.2 и 192.168.0.3 (аналогичный эффект может быть достигнут и командой ipset add foo 192.168.0.0/30).

Практически для всех типов списков, реализованных в ipset, существует общее ограничение на максимальный размер: 65536 записей.

Большинство перечисленных типов данных можно разделить на две группы: полные перечни (map, bitmap) и выборочные перечни (hash, tree). Разница между этими типами состоит в следующем: если выборочный перечень сохраняет только те элементы, которые в него входят, то полный перечень представляет собой таблицу логических значений (битов) для всех элементов, которые могут входить в данный перечень, и вхождение конкретного элемента в перечень определяется значением соответствующего бита. Полный перечень всегда формируется на базе одного непрерывного диапазона значений.

Таким образом, выбор необходимого вам типа данных определяется конкретными условиями задачи, прежде всего, отношением усредненного количества элементов в списке к требуемому диапазону охвата. Например, если вы собираетесь хранить в списке блэк-листы адресов, замеченных в атаках на ваш сервер, целесообразнее использовать тип hash:ip, потому что атакующие вас ботнеты, как бы они ни были велики, все равно занимают незначительную долю адресного пространства IPv4. К тому же, как следует из сказанного в предыдущем абзаце, тип bitmap:ip все равно не может хранить адреса, выходящие за предел одной подсети префикса 16. Но в том случае, если вам, например, нужно задать список хостов из вашей локальной сети, имеющих доступ к каким-либо услугам (службам вашего сервера, выходу в Интернет), и этот доступ должно иметь значительное количество хостов (а не единицы), то целесообразнее будет использовать bitmap:ip.

По поводу хранения адресов подсетей (блоков IP-адресов) можно сказать следующее. Если вам нужно хранить большое количество блоков одного размера из ограниченного диапазона (не более 65536 возможных значений), например, блоки /24 из подсети /8, вы можете использовать тип bitmap:ip, указав маску. Если же вам нужно хранить блоки одного размера из достаточно широкого диапазона, например, /24 из всего адресного пространства IPv4, используйте тип hash:ip, также с указанием маски. При необходимости хранить в одном списке блоки разного размера, воспользуйтесь типом hash:net.

Что касается улучшений в версиях 5 и 6 по сравнению с четвертой и более ранними, то, помимо уже упомянутых (поддержка адресов IPv6, поддержка тайм-аутов для всех типов данных, возможность сохранения идентификатора протокола транспортного уровня в типах hash:ip,port, hash:ip,port,ip и hash:ip,port,net), стоит также отметить переход на использование nfnetlink (см. выше) для связи ядра и userspace, а также более простой синтаксис. Например, те действия, которые в ipset 4 выглядели бы так:

ipset -N foo macipmap --network 192.168.0.0/16 # Создаем список
ipset -A foo 192.168.1.1,12:34:56:78:9A:BC # Добавляем запись
ipset -T foo 192.168.1.1,12:34:56:78:9A:BC # Проверяем ее наличие в списке
ipset -L foo # Выводим список на экран (точнее, на stdout)
ipset -F foo # Очищаем список
ipset -X foo # Удаляем список

в современных версиях ipset будут выглядеть следующим образом:

ipset create foo bitmap:ip,mac range 192.168.0.0/16
ipset add foo 192.168.1.1,12:34:56:78:9A:BC
ipset test foo 192.168.1.1,12:34:56:78:9A:BC
ipset list foo
ipset flush foo
ipset destroy foo

Кроме того, современные версии ipset поддерживают работу в режиме простой оболочки, принимающей команды со stdin. При этом в них обеспечивается полная обратная совместимость синтаксиса с четвертой версией, то есть синтаксис, корректно работающий для четвертой версии ipset, будет точно так же работать в пятой и шестой.

ipvs

Разработанный в рамках проекта Linux Virtual Server инструментарий для балансировки входящих соединений на транспортном уровне, позволяющий создавать отказоустойчивые (highly available, HA) кластеры с балансировкой нагрузки. В структуру такого кластера входит один или несколько хостов-балансировщиков (front-end), а также группа хостов-обработчиков (back-end). Хост-балансировщик принимает входящие соединения и перенаправляет их на хосты-обработчики, причем выбор хоста-обработчика осуществляется по специальному алгоритму, обеспечивающему гибкое распределение нагрузки между обработчиками. В кластере также могут присутствовать дополнительные (резервные) балансировщики, которые вступают в игру в случае отказа основного балансировщика.

Как правило, IPVS работает в связке с демоном keepalived, который обеспечивает отказоустойчивость балансировщика (с использованием протокола VRRP) и поддержку в актуальном состоянии списка обработчиков (демон периодически проверяет работоспособность обработчиков и выводит из состава кластера неработоспособные хосты). Также допускается «ручное» управление настройками кластера — через программу ipvsadm.

Как уже упоминалось выше, IPVS обеспечивает балансировку нагрузки на транспортном уровне, т.е. конфигурационной единицей IPVS является кластерная служба. Она характеризуется адресом (IPv4 или IPv6), протоколом транспортного уровня (на данный момент IPVS поддерживает протоколы TCP, UDP и SCTP) и номером порта. Обычно для кластерных служб выделяется отдельный адрес, который присваивается активному (на данный момент) балансировщику. В случае его отказа, адрес автоматически передается резервному балансировщику, и кластер продолжает работу. Обратите внимание, что обеспечением отказоустойчивости занимается не IPVS, а keepalived. Впрочем, использование keepalived не является строго обязательным — существуют и альтернативные подходы, например, встраивание IPVS в кластерный стек Linux-HA (см. Heartbeat). В том случае, если отказоустойчивость не критична (требуется только балансировка нагрузки), можно вообще обойтись без дополнительного демона, выполняя всю настройку через ipvsadm.

Для перенаправления пакетов на выбранный обработчик, IPVS может использовать один из следующих методов:

Прямая маршрутизация (gatewaying) — применяется в том случае, если между балансировщиком и обработчиками отсутствуют маршрутизаторы, т.е. они находятся в одном сегменте сети. В этом случае адрес назначения в заголовке пакетов сохраняется неизменным («кластерный» адрес), подменяются лишь MAC-адреса назначения при отправке кадров с этими пакетами.
Инкапсуляция IPIP — модификация предыдущего метода на тот случай, когда балансировщик и обработчики находятся в разных сегментах сети. При помощи инкапсуляции IP-в-IP создаются сетевые туннели, которые объединяют балансировщик и обработчик в один сегмент виртуальной сети.
Маскарадинг (NAT) — наиболее гибкое и универсальное решение: балансировщик подменяет адреса/порты назначения проходящих пакетов на реальные адреса/порты обработчиков (трансляция порт-адрес). При этом обеспечивается как простота настройки (не нужно поднимать дополнительные адреса на обработчиках и туннели между балансировщиком и обработчиком), так и гибкость (целевой порт обработчика может отличаться от порта кластерной службы, что невозможно в рамках других методов). Недостатком данного метода является несколько большее потребление системных ресурсов (трансляция адресов является довольно ресурсоемкой задачей).

В настоящее время существует довольно обширная библиотека алгоритмов балансировки нагрузки между обработчиками:

rr (round robin) — классическая кольцевая схема, когда все обработчики получают новые соединения поочередно.
wrr (weighted round robin) — модификация кольцевой схемы на тот случай, когда одни сервера могут обрабатывать больше соединений, чем другие. Такие сервера включаются в один проход очереди по нескольку раз, и соответственно получают больше соединений.
lc (least-connection) — новое соединение передается тому серверу, который на текущий момент обрабатывает наименьшее число соединений.
wlc (weighted least-connection) — модификация предыдущего метода на случай, когда возможности серверов отличаются. При выборе нового сервера сравниваются не непосредственно количества открытых соединений, а отношения количества соединений к весовому коэффициенту (весу) обработчика (который и характеризует его возможности).
lblc (locality-based least-connection) — формирует привязку обработчиков к кластерному адресу назначения (их может быть несколько). В том случае, если для запрошенного адреса такой привязки еще нет, или привязанный обработчик сильно перегружен — выбирает (по алгоритму lc) и привязывает новый обработчик.
lblcr (locality-based least-connection with replication) — несколько усложненный вариант предыдущего алгоритма. К каждому кластерному адресу привязывается группа обработчиков, которая периодически обновляется (исключаются наиболее нагруженные обработчики, вместо них включаются наименее нагруженные).
dh (destination hashing) — обеспечивает жесткую, неуправляемую привязку обработчиков к кластерным адресам назначения (выбор обработчика производится исключительно на основании элементарных арифметических операций над кластерным адресом и никак не учитывает загруженности обработчиков). Может привести к перегрузкам отдельных обработчиков — в этом случае кластер просто перестает обслуживать соответствующий адрес. В такой ситуации нужно либо увеличить лимит соединений на обработчик, либо выбрать другой алгоритм.
sh (source hashing) — аналогично dh, но обработчики привязываются к адресам клиентов. Как и dh, в случае перегрузки прекращает обслуживание. Отметим, что для формирования временных привязок обработчиков к адресам клиентов целесообразнее использовать механизм устойчивых соединений (persistent connections), доступный для всех алгоритмов.
sed (shortest expected delay) — выбирает сервер с наименьшей ожидаемой задержкой ответа. Эта задержка определяется как отношение числа обрабатываемых соединений плюс единица к весу обработчика. Таким образом, этот метод по принципу близок к wlc (отличается лишь прибавлением единицы к числителю сравниваемой величины, что немного меняет влияние веса обработчика на выбор).
nq (never queue) — пытается передать новое соединение обработчику, который в данный момент не обрабатывает других соединений. Если все обработчики уже заняты, использует предыдущий алгоритм (sed).

Для отслеживания соединений к кластерным службам IPVS использует собственную систему трекинга соединений, более примитивную, но менее ресурсоемкую, нежели классический conntrack. При этом поддерживается экспорт информации о кластерных соединениях в conntrack, в целях обеспечения их корректной обработки фаерволом и трансляции адресов (при трансляции адресов используются штатные средства netfilter). Однако, для корректной обработки протоколов, использующих связанные соединения (например, FTP), IPVS использует возможности conntrack. Синхронизация таблицы соединений между основным и дублирующими балансировщиками полностью реализована на уровне ядра (для сравнения, в conntrack эту задачу выполняет userspace-демон conntrackd).

Механизм определения состояний

Важной особенностью iptables/netfilter является механизм определения состояний (connection tracking, nf_conntrack) — специальная подсистема, отслеживающая состояния соединений и позволяющая использовать эту информацию при принятии решений о судьбе отдельных пакетов. Наличие этого механизма делает netfilter полноценным stateful-фаерволом.

Определение состояния соединения порою бывает довольно сложной задачей. Скажем, в случае TCP все относительно просто — контроль состояний реализован средствами самого протокола, установлены специальные процедуры открытия и закрытия соединения. А вот в протоколе UDP для этого специальных процедур не предусмотрено, поэтому UDP-соединением с точки зрения conntrack является поток пакетов, следующих с интервалом, не превышающим заданный тайм-аут (sysctl-параметр net.netfilter.nf_conntrack_udp_timeout, по умолчанию 30 секунд), с одного и того же порта одного хоста, на один и тот же порт другого хоста.

Заметим, что классификация пакетов по отношению к соединениям, реализуемая системой conntrack, во многих случаях отличается от официального описания сетевых протоколов. Например, с точки зрения критерия conntrack, TCP-пакет SYN/ACK (отвечающий на SYN) — уже часть существующего сеанса, а по определению TCP такой пакет — всего лишь элемент открытия сеанса.

Существует также понятие «связанных соединений». Например, когда в ответ на UDP-пакет с нашего хоста удаленный хост отвечает ICMP-пакетом icmp-port-unreachable, формально этот ответ является отдельным соединением, так как использует совсем другой протокол. netfilter отслеживает подобные ситуации и присваивает таким соединениям статус «связанных» (RELATED), позволяя корректно пропускать их через фильтры фаервола.

Более сложный вариант связанного соединения — соединение данных в пассивном режиме FTP. FTP-сервер самостоятельно выбирает порт для прослушивания из достаточно большого диапазона, и сообщает номер порта клиенту через управляющее соединение, после чего клиент подключается к этому порту и передает данные. netfilter, а точнее модуль conntrack_ftp, выделяет в потоке данных управляющего соединения нужный номер порта, что позволяет корректно определить новое соединение как связанное и, соответственно, корректно пропустить его через правила фильтрации.

В некоторых случаях целесообразно отключить отслеживание состояния соединений. Например, если ваш сервер находится под (D)DoS-атакой типа флуд, и вам удалось локализовать ее источники, отслеживать соединения с атакующих хостов и тратить для этого ресурсы своей системы явно не имеет смысла. В подобных случаях используется действие NOTRACK, применяемое в таблице raw.

Ниже кратко перечислены возможности, предоставляемые системой отслеживания состояний:

Критерий состояния соединения

При помощи критерия conntrack вы можете классифицировать пакеты на основании их отношения к соединениям. В частности, состояние NEW позволяет выделять только пакеты, открывающие новые соединения, состояние ESTABLISHED — пакеты, принадлежащие к установленным соединениям, состоянию RELATED соответствуют пакеты, открывающие новые соединения, логически связанные с уже установленными (например, соединение данных в пассивном режиме FTP). Состояние INVALID означает, что принадлежность пакета к соединению установить не удалось.

Например, одним простым правилом

iptables -I INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

вы можете обеспечить корректное пропускание всех входящих пакетов, принадлежащих установленным соединениям, и сконцентрироваться только на фильтрации новых соединений.

Заменив в предыдущем правиле ESTABLISHED на ESTABLISHED,RELATED и подгрузив соответствующие модули ядра, вы автоматически обеспечите корректную фильтрацию протоколов, использующих связанные соединения — FTP, SIP, IRC, H.323 и других. Такое простое (с точки зрения пользователя) решение сложной (с технической точки зрения) проблемы является безусловным достоинством фаервола netfilter и ядра Linux в целом.

Более подробно об использовании этого критерия вы можете почитать ниже.

Кроме критерия conntrack, стоит упомянуть и его идеологического предшественника — критерий state. Изначально для определения состояния соединения использовался именно он, то есть вместо -m conntrack —ctstate ESTABLISHED,RELATED использовалось -m state —state ESTABLISHED,RELATED. Подобные формулировки до сих пор сохраняются во многих руководствах по iptables. Однако в настоящее время критерий state считается устаревшим, и разработчики iptables рекомендуют использовать вместо него критерий conntrack. Также заметим, что критерий conntrack обладает более широкими возможностями, нежели state, и позволяет использовать дополнительную информацию о соединении, в частности, состояние самого соединения (ctstatus), факт применения к нему трансляции адресов, тайм-аут для «повисших» соединений (ctexpire) и т. п.

Маркировка соединений

Этот прием позволяет классифицировать соединение в целом на основании информации об отдельном пакете. Выделив этот пакет, вы применяете к нему действие CONNMARK, и выбранную вами маркировку автоматически приобретают все пакеты в соединении. Впоследствии вы можете, например, модифицировать эти пакеты каким-либо образом, или использовать эту маркировку для маршрутизации или шейпинга пакетов. Таким образом, вы оперируете с соединением как с единым целым. Более того, эта маркировка автоматически копируется и на соединения, связанные с текущим.

Трансляция сетевых адресов

В операциях NAT, производимых с помощью iptables, отслеживание состояний используется автоматически. Вам достаточно указать критерии, под которые подпадет лишь первый пакет в соединении — и трансляция адресов будет применена ко всем пакетам в этом соединении, а также в связанных с ним соединениях.

Использование статистики по соединениям

Применяя критерий connbytes, вы можете контролировать количество байт или пакетов, переданных по каждому конкретному соединению. В простейшем случае этот механизм может использоваться, скажем, для назначения квот. Более сложный пример — шейпинг пакетов в зависимости от «весовой категории» соединения (ставить пониженный приоритет загрузкам больших файлов).

Этот критерий рассмотрен ниже, в разделе лимитирующие критерии.

Ограничение количества соединений

Используя критерий connlimit, вы можете ограничивать количество одновременно открытых TCP-соединений с каждого хоста или подсети на ваш сервер, что позволяет обеспечить эффективную защиту от DoS-атак или просто некорректно работающего клиентского ПО.

Этот критерий рассмотрен ниже, в разделе лимитирующие критерии.

Отслеживание информации о соединениях

Пользователь (точнее, системный администратор) или его процессы могут непосредственно наблюдать таблицу контроля состояний, считывать статистику по передаче данных, а также модифицировать эту таблицу (например, удалять из нее соединения). Для этого существуют специальные утилиты, такие как conntrack или iptstate. Впрочем, можно читать информацию и напрямую из псевдофайлов /proc/net/nf_conntrack и /proc/net/nf_conntrack_expect.

Действия

Переходы

Для организации перехода пакета из текущей цепочки в другую (определенную пользователем), просто используйте действие -j имя_цепочки. В случае применения в этой цепочке к пакету действия RETURN (см. ниже), пакет вернется в исходную цепочку и продолжит ее прохождение начиная со следующего правила.

Также, существует довольно редко используемое действие «безвозвратного перехода» -g имя_цепочки. В таком случае, после прохождения пакетом этой цепочки либо при применении в этой цепочке к пакету действия RETURN, пакет вернется к месту последнего перехода по -j. Если таких переходов не было, к пакету сразу будет применено действие по умолчанию для базовой цепочки.

Заметим, что не стоит пытаться перейти в базовую цепочку (например, -j OUTPUT), в текущую цепочку (во избежание зацикливания), а также в цепочку, определенную в другой таблице.

Встроенные действия

Как уже было сказано выше, каждое встроенное действие реализует какую-либо одну операцию, например, ACCEPT пропускает пакет, MARK меняет его маркировку, MASQUERADE обеспечиват маскарадинг соединения. Наиболее общими действиями являются:

ACCEPT, DROP и REJECT — базовые операции фильтрации. Более подробно они рассмотрены ниже, при описании таблицы filter.
RETURN — обеспечивает возврат из текущей цепочки. В частности, если из цепочки A правилом номер 3 пакет был направлен в цепочку B, то применение к нему в цепочке B действия RETURN приведет к его переходу обратно в цепочку A, и он продолжит ее прохождение со следующего правила (номер 4).

Например, предположим, что нам нужно обеспечить доступ к определенным портам нашего сервера для всех хостов из подсети 10.134.0.64/26, кроме 10.134.0.67 и 10.134.0.100.

iptables -F # Очищаем все цепочки таблицы filter
iptables -N our_subnet # Создаем специальную цепочку для проверки пакетов из нашей подсети
iptables -A our_subnet -s 10.134.0.67 -j RETURN # Запрещенный хост — выходим
iptables -A our_subnet -s 10.134.0.100 -j RETURN # Запрещенный хост — выходим
# Всем остальным разрешаем доступ к нужным портам
iptables -A our_subnet -p tcp -m multiport --dports 22,53,8080,139,445 -j ACCEPT
iptables -A our_subnet -p udp -m multiport --dports 53,123,137,138 -j ACCEPT
iptables -A our_subnet -p icmp --icmp-type 8 -j ACCEPT
# Разрешаем пакеты по уже установленным соединениям
iptables -A INPUT -m conntrack --cstate ESTABLISHED,RELATED -j ACCEPT
# Все пакеты из нашей подсети отправляем на проверку
iptables -A INPUT -s 10.134.0.64/26 -j our_subnet
iptables -P INPUT DROP # Что не разрешено — то запрещено
iptables -P OUTPUT ACCEPT # На выход — можно все

Теперь все новые входящие пакеты, отправленные из нашей подсети 10.134.0.64/26, отправляются на проверку в цепочку our_subnet. К пакетам с «запрещенных» хостов применяется операция RETURN, и они покидают эту цепочку и впоследствии блокируются действием по умолчанию цепочки INPUT. Пакеты с остальных хостов этой подсети пропускаются в том случае, если они адресованы на порты прокси (8080/tcp), SSH (22/tcp), SMB (139,445/tcp, 137,138/udp), DNS (53/tcp, udp), NTP (123/udp). Также для этих хостов разрешены ICMP-эхо-запросы (пинги). Все остальные пакеты (включая пакеты не из нашей подсети, пакеты с запрещенных хостов и пакеты на неразрешенные порты) блокируются действием по умолчанию DROP.

Нетрудно заметить, что в нашем простом примере вместо RETURN можно было использовать и DROP. Однако, существует понятие «принципа одного запрета». При организации фильтрующих правил в рамках этого принципа, сначала следует серия разрешающих правил, исключения оформляются в виде RETURN, а все не разрешенные пакеты доходят до конца базовой цепочки и блокируются действием по умолчанию либо последним правилом. Следование этому принципу позволяет достичь гибкости в выборе и смене метода блокирования пакетов. Допустим, вы хотите сменить блокирующее действие DROP на REJECT. Нет ничего проще — просто меняете правило по умолчанию. Так же просто вводятся специфические методы блокировки для TCP, например, REJECT —reject-with tcp-reset или DELUDE — достаточно просто добавить это действие (вместе с указанием протокола -p tcp) в конец цепочки. Все не-TCP пакеты при этом будут по-прежнему блокироваться действием по умолчанию.

Впрочем, изложенный принцип теряет первоначальный смысл, если в разных случаях нужно обеспечить разные способы блокирования. Рассмотрим чуть более сложный пример: допустим, наш сервер подключен к локальной сети 10.0.0.0/8. В ней есть некий «недоверенный» сегмент, скажем, 10.122.0.0/16, для которого нужно полностью заблокировать доступ к нашему серверу. Но в этом сегменте есть несколько «хороших» хостов (скажем, 10.122.72.11 и 10.122.180.91), которые блокировать не нужно. Поставленную задачу можно решить следующим образом:

iptables -F # Очищаем все цепочки таблицы filter
iptables -N check_untrusted # Создаем специальную цепочку для проверки пакетов из нашей подсети
iptables -A check_untrusted -s 10.122.72.11 -j RETURN # Разрешенный хост — выходим
iptables -A check_untrusted -s 10.122.180.91 -j RETURN # Разрешенный хост — выходим
iptables -A check_untrusted -j DROP # Остальных — молча игнорируем
# Разрешаем пакеты по уже установленным соединениям
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Пакеты из недоверенной подсети проверяем по списку
iptables -A INPUT -s 10.122.0.0/16 -j check_untrusted
# Всем остальным разрешаем доступ к нужным портам
iptables -A INPUT -p tcp -m multiport --dports 22,53,8080,139,445 -j ACCEPT
iptables -A INPUT -p udp -m multiport --dports 53,123,137,138 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT
# «Хорошим» хостам, обращающимся на неправильные TCP-порты, вежливо сообщаем об отказе
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
# Для всех остальных протоколов используем стандартный REJECT с icmp-port-unreachable
iptables -P INPUT REJECT
iptables -P OUTPUT ACCEPT # На выход — можно все

Заметим, что в данном примере хосты из недоверенного сегмента блокируются «молча» (DROP), в то время как при обращении «хороших» хостов на неправильные порты сервер вежливо сообщает им об отказе (REJECT). Этот принцип также является очень важным при построении фаерволов — чем меньше информации попадает к потенциальному злоумышленнику, тем лучше, поэтому на опасных направлениях целесообразно использовать «молчаливое» блокирование, в то время как явные сообщения для «своих» упрощают диагностику работы сети и поиск ошибок.

Примечание: следующий пример планируется к переносу в еще не написанный раздел статьи (Прочие критерии → mac).

Например, предположим, что у нас есть объединенная через один свитч подсеть 10.134.0.64/26, к которой наш компьютер подключен через интерфейс eth1. Тогда защиту от спуфинга (подделки адресов отправителя) через проверку MAC-адреса можно обеспечить следующим образом:

sysctl net.ipv4.ip_forward=1 # Разрешаем шлюзу передавать транзитный трафик
iptables -F # Очищаем все цепочки таблицы filter
iptables -N check_ours_sp00f # Создаем цепочку, в которой будут проверяться MAC-адреса
iptables -A check_ours_sp00f -s 10.134.0.67 -m mac --mac-source 00:1D:60:2E:ED:A5 -j RETURN
iptables -A check_ours_sp00f -s 10.134.0.68 -m mac --mac-source 00:1D:60:2E:ED:CD -j RETURN
iptables -A check_ours_sp00f -s 10.134.0.69 -m mac --mac-source 00:1D:60:2E:ED:D7 -j RETURN
iptables -A check_ours_sp00f -s 10.134.0.70 -m mac --mac-source 00:1D:60:2E:ED:E0 -j RETURN
# Аналогичным образом проверяем все адреса нашей подсети
# И в конце обязательно добаляем правило для НЕпрошедших проверку
iptables -A check_ours_sp00f -j DROP
iptables -N check_ours # Создаем цепочку, которая будет описывать логику работы с нашей подсетью
iptables -A check_ours ! -i eth1 -j DROP # С других интерфейсов пакеты от них прийти не могут
iptables -A check_ours -j check_ours_sp00f # Прогоняем их через проверку на спуфинг
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Как обычно, пропускаем все, что идет по установленным соединениям
iptables -A INPUT -s 10.134.0.64/26 -j check_ours # Тех, кто претендует на звание своих, прогоняем через проверку
# Прошедшим проверку разрешаем пользоваться нащей проксёй и самбой, а также соединяться по ssh
iptables -A INPUT -s 10.134.0.64/26 -m multiport --dports 22,8080,139,445 -j ACCEPT
iptables -P INPUT DROP # Остальных блокируем
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Как обычно, пропускаем все, что идет по установленным соединениям
iptables -A FORWARD -s 10.134.0.64/26 -j check_ours # Проверка
iptables -A FORWARD -s 10.134.0.64/26 -j ACCEPT # Прошедшим проверку разрешаем передавать через нас транзитный трафик
iptables -P FORWARD DROP # Остальных блокируем
iptables -P OUTPUT ACCEPT # Исходящий трафик разрешаем

Все новые входящие пакеты с обратным адресом из подсети 10.134.0.64/26 проходят двойную проверку в цепочке check_ours. Первый этап проверки — соответствие интерфейса. Ведь к нашей подсети, по условию задачи, мы подключены только интерфейсом eth1. Если пакет якобы из этой подсети придет с любого другого интерфейса, он будет заблокирован. Второй этап проверки заключается в последовательном чтении списка соответствующих IP- и MAC-адресов (цепочка check_ours_sp00f). Каждое правило этой цепочки, кроме последнего, выделяет пакеты от одного конкретного хоста нашей подсети. К пакетам, прошедшим проверку, применяется операция RETURN, выводящая пакет из этой цепочки. Если же пакет не подошел ни по одному из этих правил, он считается не прошедшим проверки и блокируется последним правилом -j DROP. Для прошедших же проверку пакетов дальнейшая судьба зависит от того, кому они адресованы. Если они идут через наш хост в другие подсети, то они пропускаются. Если же они адресованы непосредственно нашему хосту, то пропускаются только соединения на некоторые TCP-порты (прокси, SSH, SMB).

LOG — позволяет записывать информацию о пакетах в журнал ядра (см. syslog).

Например, если в предыдущем примере перед строкой

iptables -A INPUT -p tcp -m multiport --dports 22,53,8080,139,445 -j ACCEPT

мы добавим строку

iptables -A INPUT -p tcp -m multiport --dports 22,53,8080,139,445 -j LOG --log-level INFO --log-prefix "New connection from ours: "

то для каждого нового соединения к нашему хосту из нашей подсети в системном журнале будет появляться запись примерно такого вида:

Jul 16 20:10:40 interdictor kernel: New connection from ours: IN=eth0 OUT= MAC=00:15:17:4c:89:35:00:1d:60:2e:ed:a5:08:00 SRC=10.134.0.67 
DST=10.134.0.65 LEN=48 TOS=0x00 PREC=0x00 TTL=112 ID=38914 DF PROTO=TCP SPT=31521 DPT=8080 WINDOW=65535 RES=0x00 SYN URGP=0

Такая запись содержит очень много полезной информации. Начинается она с даты и времени получения пакета. Затем идет имя нашего хоста (interdictor) и источник сообщения (для сообщений фаервола это всегда ядро). Потом идет заданный нами префикс (New connection from ours:), после чего следуют данные о самом пакете: входящий интерфейс (определен для цепочек PREROUTING, INPUT и FORWARD), исходящий интерфейс (определен для цепочек FORWARD, OUTPUT и POSTROUTING), далее — сцепленные вместе MAC-адреса источника и назначения (сначала идет адрес назначения, в данном случае это наш интерфейс eth1 с маком 00:15:17:4C:89:35, затем адрес источника, в нашем случае это 00:1D:60:2E:ED:A5, и в конце следует значение EtherType, 08:00 соответствует протоколу IPv4^[2]), потом IP-адреса источника (10.134.0.67) и получателя (10.134.0.65, это наш хост), а затем идет различная техническая информация. Например, протокол (TCP), порты источника и назначения (31521 и 8080 соответственно), TOS и TTL, длина пакета (48 байт), наличие флага SYN и т. д.

Указав соответствующие параметры действия LOG, можно дополнить эту информацию номером TCP-последовательности (опция —log-tcp-sequence), выводом включенных опций протоколов TCP (опция —log-tcp-options) и IP (—log-ip-options), а также идентификатором пользователя, процесс которого отправил данный пакет (—log-uid, имеет смысл только в цепочках OUTPUT и POSTROUTING).

Параметр —log-prefix позволяет задать поясняющую надпись, упрощающую поиск сообщений в системных журналах. Параметр —log-level определяет уровень важности лог-сообщения, от которого зависит, в частности, в какой именно из журналов будет записано это сообщение. За более подробными сведениями обратитесь к документации по вашему демону системного лога.

LOGMARK — специальная модификация действия LOG, реализованная в комплекте xtables-addons. Отличается тем, что заносит в лог информацию, специфичную для системы conntrack, в частности, маркировку соединения (connmark aka ctmark), состояния соединения (ctstate и ctstatus) и т. п. Например:

 Jul 16 20:10:40 interdictor kernel: New connection from ours: iif=1 hook=INPUT nfmark=0x0 secmark=0x0 classify=0x0 ctdir=ORIGINAL 
 ct=0xf5436bcc ctmark=0x0 ctstate=NEW ctstatus=

iif показывает внутренний идентификатор интерфейса, через который прошел пакет (1 в данном случае соответствует eth0, 0 — lo), hook — имя цепочки, из которой было вызвано действие LOGMARK, nfmark — маркировку пакета (mark), secmark — контекст безопасности SELinux данного пакета (secmark), classify — класс шейпера (также известный как skb->priority, соответствует обычной для tc форме записи MAJOR:MINOR согласно формуле skb->priority == MAJOR << 16 | MINOR), ctdir — направление передачи информации с точки зрения conntrack, ct — внутренний идентификатор соединения в системе conntrack (точнее говоря, адрес в памяти, по которому расположена структура, хранящая информацию о соединении), ctmark — маркировку соединения (connmark), ctstate — состояние соединения, ctstatus — статус соединения в системе cоnntrack. Более подробно о параметрах ctdir, ctstate и ctstatus вы можете прочитать ниже, в описании критерия conntrack. Здесь же ограничимся замечаниями, что «ctstate=NEW ctstatus=» соответствует первому пакету в соединении, «ctstate=ESTABLISHED ctstatus=SEEN_REPLY,CONFIRMED» — второму и нескольким последующим пакетам, «ctstate=ESTABLISHED ctstatus=SEEN_REPLY,ASSURED,CONFIRMED» — пакетам в полностью установленном соединении, «ct=NULL ctmark=NULL ctstate=INVALID ctstatus=NONE» — пакету, который не удалось отнести к существующим соединениям, «ct=UNTRACKED ctmark=NULL ctstate=UNTRACKED ctstatus=NONE» — пакету, для которого была отключена трассировка conntrack (обычно это выполняется действием NOTRACK в таблице raw, см. ниже).

Таким образом, в сочетании с традиционным LOG, действие LOGMARK позволяет заносить в системный журнал исчерпывающую информацию о пакетах и соединениях.

Заметим, что LOGMARK принимает описанные выше опции —log-prefix и —log-level.

ULOG — позволяет передавать информацию об обработанных пакетах специальным демонам, таким, как ulogd. Такой подход позволяет эффективно управлять информацией о трафике, в частности, заносить ее в базы данных, такие как MySQL, PostgreSQL или SQLite. Впоследствии эти данные могут быть проанализированы и визуализированы с помощью таких средств, как NuLog.
NFLOG — более универсальный вариант ULOG, обеспечивающий передачу информации о пакете не напрямую в netlink-сокет (как это делает ULOG), а специальной подсистеме — logging backend. Например, бэкенд nfnetlink_log обеспечивает передачу данных в netlink-сокет, то есть с ним NFLOG работает аналогично ULOG.
NFQUEUE — во многом похоже на ULOG, но передает специальному демону не информацию о пакете, а сам пакет целиком. Применяется, в частности, для организации работы l7-filter-userspace.

Например, если демон l7-filter был запущен командой

l7-filter -f /etc/l7-filter.conf -q 2

то передать ему на обработку все входящие и локально сгенерированные пакеты можно командами

iptables -t mangle -F # На всякий случай очищаем таблицу mangle
iptables -t mangle -A PREROUTING -j NFQUEUE --queue-num 2
iptables -t mangle -A OUTPUT -j NFQUEUE --queue-num 2

Опция —queue-num позволяет указать номер очереди пакетов. Он должен быть совпадать с номером, указанным при запуске демона l7-filter (параметр -q).

QUEUE — устаревшая версия NFQUEUE. Не имеет параметров, так как работает только с очередью номер 0.

Выше были рассмотрены действия «общего назначения», то есть не привязанные по своей специфике к таблицам. Далее, при рассмотрении отдельных таблиц, будут описываться действия, специфичные для каждой таблицы. Термин «специфичные» надо понимать так: совсем не обязательно, что действие, специфичное для одной таблицы, будет в принципе недопустимо в другой, но в любом случае использование этого действия в других таблицах будет «плохим тоном» — ведь таблицы и действия четко разделены по назначению. Не стоит «забивать гвозди микроскопом».

Порой эта разница бывает довольно тонкой. Например, если действие NFQUEUE передает пакеты демону l7-filter-userspace (который занимается маркировкой пакетов на основе анализа их содержимого), то правильнее будет разместить вызов такого действия в таблице mangle. Если же оно передает пакеты демону nufw (который обеспечивает разрешение или запрещение трафика на основе авторизации пользователя), то логичнее разместить это действие в таблице filter.

Кроме того, существуют и ограничения, наложенные непосредственно в коде iptables. Например, действия таблицы nat жестко защищены от употребления за ее пределами. Другой пример: действие REDIRECT можно применять только в цепочках PREROUTING и OUTPUT таблицы nat, то есть ограничения могут быть не только на таблицы, но на отдельные цепочки. Данная статья ни в коем случае не претендует на полноту изложения, поэтому, перед тем как использовать какое-либо действие, обязательно ознакомьтесь с документацией, прилагающейся к вашей версии iptables.

Терминальные и нетерминальные действия

Терминальными называются действия, которые прерывают прохождение пакета через текущую базовую цепочку. То есть если к пакету в рамках некоторого правила было применено терминальное действие, он уже не проверяется на соответствие всем следующим правилам в этой цепочке (и в тех цепочках, из которых она была вызвана, если это пользовательская цепочка). Терминальными являются все действия, специфичные для таблиц filter и nat. Из приведенных выше в этом разделе — ACCEPT, DROP, REJECT, NFQUEUE, QUEUE.

Например,

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j LOG --log-prefix "IN HTTP: "

Второе из приведенных правил (логгирование) никогда не будет срабатывать, так как все пакеты, удовлетворяющие этому критерию (входящие TCP-пакеты на порт 80), будут пропущены по первому из этих правил, и до второго просто не дойдут.

Нетерминальными, соответственно, являются действия, не прерывающие процесс прохождения пакета через цепочки. Нетерминальными являются действия, специфичные для таблицы mangle, а из перечисленных выше — LOG, ULOG и NFLOG.

Например,

iptables -A INPUT -p tcp --dport 80 -j LOG --log-prefix "IN HTTP: "
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Теперь все входящие на TCP-порт 80 пакеты будут сначала заноситься в лог, и только потом пропускаться.

Действие RETURN с точки зрения такой классификации занимает промежуточное положение — оно может прервать прохождение пакета через отдельную цепочку (или несколько цепочек, если для перехода в них использовалась опция -g, а не -j), но совсем не обязательно, чтобы это приводило к завершению обработки пакета в рамках текущей базовой цепочки.

Таблицы

Таблица mangle

Данная таблица предназначена для операций по классификации и маркировке пакетов и соединений, а также модификации заголовков пакетов (поля TTL и TOS).

Цепочки

Таблица mangle содержит следующие цепочки:

PREROUTING — позволяет модифицировать пакет до принятия решения о маршрутизации.
INPUT — позволяет модифицировать пакет, предназначенный самому хосту.
FORWARD — цепочка, позволяющая модифицировать транзитные пакеты.
OUTPUT — позволяет модифицировать пакеты, исходящие от самого хоста.
POSTROUTING — дает возможность модифицировать все исходящие пакеты, как сгенерированные самим хостом, так и транзитные.

Заметим, что все цепочки таблицы mangle пакеты проходят раньше, чем одноименные цепочки таблиц nat и filter. Это позволяет классифицировать и маркировать пакеты и соединения в цепочках этой таблицы. Впоследствии эти маркировки могут быть использованы в цепочках двух других таблиц при принятии решений о фильтрации и трансляции адресов.

Действия

Допустимыми действиями в этой таблице являются:

TOS — изменяет поле TOS данного пакета. Поддерживаются опции —set-tos (установить поле TOS в заданное значение), а также —and-tos, —or-tos и —xor-tos, комбинирующие текущее значение поля TOS с заданным в правиле значением по соответствующему логическому правилу и записывающие результат как новое значения поля TOS.

Кроме того, опция —set-tos поддерживает расширенный синтаксис —set-tos значение/маска. При использовании такого синтаксиса в исходном значении TOS пакета зануляются те биты, которые установлены в маске, затем полученное число XOR’ится с указанным в параметрах значением, и полученная величина записывается в поле TOS. Используя синтаксис языка C, это можно записать так: NEW_TOS = (OLD_TOS & ~маска) ^ значение. Заметим, что в случае с IPv6 операция отрицания маски не выполняется (то есть в исходном значении зануляются те биты, которые в маске не установлены), хотя это и не отражено в документации.

Также, в случае IPv4 (iptables) в параметре —set-tos вы можете указать одно из допустимых символьных обозначений: Minimize-Delay (TOS 16, требование минимальной задержки), Maximize-Throughput (TOS 8, требование максимальной пропускной способности), Maximize-Reliability (TOS 4, максимальная надежность доставки), Minimize-Cost (TOS 2, минимальная стоимость), Normal-Service (TOS 0, специальные требования отсутствуют). В ip6tables использование этих обозначений не запрещено, однако в этом случае более корректным будет использование действия DSCP (см. ниже).

Практический пример использования действия TOS представлен ниже, в описании критерия connbytes.

Отметим, что, в соответствии с современными соглашениями, поле TOS в заголовке IP-пакета разделяется на две части: DSCP (первые шесть бит кода TOS) и ECN (последние два бита TOS). Современные версии netfilter/iptables не поддерживают изменение значений ECN в IP-заголовках, поэтому фактически действие TOS работает только с полем DSCP, отличаясь от действия DSCP (см. чуть ниже) разве что интерфейсом (фактически, синтаксисом).

DSCP — изменяет поле DSCP (класс DiffServ) в заголовке пакета. Поддерживаются опции —set-dscp (позволяет задать значение DSCP числом) и —set-dscp-class (позволяет установить заданный класс DiffServ, например, EF или AF13).

TTL — изменяет поле TTL данного пакета (работает только с IPv4, для IPv6 используется действие HL). Поддерживаются опции —ttl-set (установить поле TTL в заданное значение), а также —ttl-inc и —ttl-dec (соответственно увеличить или уменьшить текущее значение поля TTL на заданное значение). Допустимые значения TTL — от 0 до 255. При достижении TTL=0 пакет уничтожается.

В качестве полезного примера использования этого действия можно привести команду

iptables -t mangle -I PREROUTING -j TTL --ttl-inc 1

делающую наш шлюз невидимым для большинства трассировщиков.

Обратите внимание, что автоматически выполняемая сетевым стеком ядра операция уменьшения TTL на единицу и проверки на равенство нулю выполняется после цепочки PREROUTING, но до цепочки FORWARD. Таким образом, переместив это правило в цепочку FORWARD, вы обеспечите «невидимость» следующего за вами шлюза.

Другой полезный пример — выравнивание TTL на выходе в Интернет (интерфейс eth0)

iptables -t mangle -I POSTROUTING -o eth0 -j TTL --ttl-set 64

Некоторые домашние провайдеры, пытаясь бороться с нелегальной перепродажей канала их клиентами, блокируют доступ тем клиентам, на выходе которых замечены пакеты с разными значениями TTL, потому что этот факт косвенно указывает на наличие у клиента внутренней подсети. Предложенное правило, будучи применено на шлюзе такой подсети, делает ее детекцию по TTL крайне затруднительной.

Будьте очень осторожны с правилами, которые увеличивают или, что особенно опасно, напрямую задают значение TTL, так как, при наличии определенных ошибок маршрутизации, это может привести к появлению «бессмертных» пакетов, которые будут долго циркулировать между одними и теми же узлами, захламляя канал и затрудняя работу сетевого оборудования.

HL — изменяет поле Hop Limit в заголовке IPv6-пакета. Является аналогом IPv4-действия TTL и поддерживает те же операции: —hl-set (установить поле HL в заданное значение), а также —hl-inc и —hl-dec (соответственно увеличить или уменьшить текущее значение поля HL на заданное значение).

MARK — устанавливает или изменяет маркировку пакета. Поддерживает опции —set-mark, —and-mark, —or-mark и —xor-mark, аналогичные опциям действия TOS. Важно понимать, что маркировка пакета не хранится в его заголовке или содержимом, и поэтому действует только в пределах одного хоста. Также нужно отличать маркировку пакета от маркировки соединения. Маркировка пакетов может применяться для их дальнейшей обработки фаерволом (критерии mark и connmark), а также для классификации трафика фильтрами шейпинговой подсистемы tc (лексема handle mark fw).
CONNMARK — устанавливает или изменяет маркировку соединения. Поддерживает те же опции, что и MARK, а также дополнительные опции —restore-mark (копирует маркировку соединения в маркировку пакета) и —save-mark (копирует маркировку пакета в маркировку соединения).
CLASSIFY — устанавливает CBQ-класс пакета для его последующей обработки шейпером (опция —set-class).
TCPMSS — устанавливает максимальный размер TCP-сегмента. Бывает крайне полезной при использовании VPN-подключения^[3] в том случае, если VPN-сервер блокирует ICMP-сообщения destination unreachable/fragmentation needed (тип 3, код 4), тем самым нарушая работу процедуры Path MTU discovery.

С точки зрения клиента, эта проблема выглядит так: пинги проходят нормально, но при попытке открыть какую-либо веб-страницу, браузер «подвисает». При этом с самого шлюза все работает нормально. В этом случае достаточно применить на шлюзе следующую команду

iptables -t mangle -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

которая обеспечит автоматическую установку размера сегмента в TCP-заголовках SYN- и SYN,ACK-пакетов в соответствии с минимальным из известных нашему шлюзу значений MTU на пути следования пакета. Например, если пакет пришел с интерфейса eth0 (MTU 1500) и уходит через интерфейс ppp0 (MTU 1492), а суммарный размер заголовков сетевого и транспортного уровней составляет 40 байт (20 байт TCP и 20 байт IP), то целесообразно установить MSS равным 1452 байтам.

Помимо возможности автоматического выбора TCP MSS, вы можете задать необходимое значение и вручную, используя параметр —set-mss значение. Это бывает полезным в том случае, если вам заведомо известно, что дальше на маршруте встречаются участки с еще меньшим MTU, а пограничные сервера этих участков опять же блокируют ICMP destination unreachable/fragmentation needed.

ECN — обеспечивает обнуление ECN-битов (флаги CWR и ECE) в TCP-заголовке (единственная опция —ecn-tcp-remove). Может использоваться только в IPv4-модуле (iptables, но не ip6tables) для TCP-пакетов (-p tcp). Данное действие предназначено для защиты пакетов от ECN blackholes (маршрутизаторов, которые некорректно обрабатывают пакеты с установленными в TCP-заголовке ECN-битами) — рекомендуется применять это действие ко всем пакетам, уходящим на такие маршрутизаторы. Обратите внимание, что данное действие никак не влияет на ECN-биты в IP-заголовках (последние два бита поля TOS).

Кроме того, данное действие поддерживает три потенциально опасные опции, не отраженные в документации: —ecn-tcp-cwr (установка значения бита CWR в TCP-заголовке, 0 или 1), —ecn-tcp-ece (установка значения бита ECE в TCP-заголовке, 0 или 1) и —ecn-ip-ect (установка значения ECT codepoint в IPv4-заголовке, от 0 до 3). Использование этих опций настолько опасно, что они не отражены даже во встроенной справке iptables (iptables -j ECN -h) — их можно увидеть, только изучив исходный код. Без крайней необходимости применять их не рекомендуется.

TCPOPTSTRIP — выполняет удаление заданных TCP-опций из заголовка TCP-пакета (единственный параметр —strip-options значение[,значение[,…]]). Удаляемые опции могут быть указаны через их номера (согласно списку на сайте IANA) или в виде символьных обозначений (список обозначений, поддерживаемых в вашей версии iptables можно посмотреть, выполнив команду iptables -j TCPOPTSTRIP -h). Разумеется, данное действие допустимо только для протокола TCP (-p tcp). Например,

iptables -t mangle -A POSTROUTING -p tcp -j TCPOPTSTRIP --strip-options timestamp

обеспечит удаление штампов времени (RFC 1323). С одной стороны, такое правило будет препятствовать удаленному злоумышленнику определить аптайм нашего хоста, а также тех хостов, маршрут от которых до злоумышленника проходит через наш хост. С другой стороны, блокирование штампов времени может негативно сказаться на быстродействии сети, особенно если вы используете подключения на скорости 100 МБит и выше. Заметим также, что если вам нужно управлять использованием именно штампов времени для TCP IPv4-пакетов, исходящих от вашего хоста, вы можете воспользоваться sysctl-параметром net.ipv4.tcp_timestamps (1 — штампы включены, 0 — выключены).

TPROXY — реализует механизм полностью прозрачного проксирования. Такой подход отличается от традиционно используемого «прозрачного» проксирования (действие REDIRECT таблицы nat, см. ниже) тем, что заголовок пакета никак не модифицируется, в том числе не заменяется IP-адрес назначения (при традиционном прозрачном проксировании он заменяется на адрес проксирующего хоста). Кроме того, полностью прозрачное проксирование является прозрачным с точки зрения обеих общающихся сторон. Например, при проксировании обращений некоторой подсети клиентов к серверам из другой подсети, можно сделать так, чтобы не только клиенты считали, что обращаются напрямую к серверам, но и сервера «видели» настоящие исходные адреса клиентов и могли бы устанавливать с ними обратные соединения (например, в случае активного режима FTP). При традиционном же «прозрачном» проксировании, сервера могут видеть только адрес прокси-сервера.

TPROXY позволяет перенаправить транзитный пакет на локальный сокет типа AF_INET (iptables) или AF_INET6 (ip6tables), заданный портом, а также может промаркировать пакет таким образом, чтобы система марушрутизации (iproute2) не позволила пакету покинуть наш хост. Разумеется, поддержка полностью прозрачного проксирования должна быть реализована и в самом прокси-сервере. В частности, прозрачное проксирование IPv4 HTTP поддерживается прокси-сервером Squid начиная с версии 3.1.

В качестве примера можно привести простейший случай конфигурации iptables и iproute2 для обеспечения полностью прозрачного проксирования IPv4 HTTP.

# Добавляем принудительную локальную маршрутизацию для всех адресов в таблицу 120
ip route add local 0.0.0.0/0 dev lo table 120
# Все пакеты, имеющие соответствующую маркировку, направляем в эту таблицу
ip rule add fwmark 120 table 120
# Выполняем проксирование для новых соединений
iptables -t mangle -I PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 120 --on-port 3129
# Перехватываем, маркируем и пропускаем пакеты, принадлежащие проксируемым соединениям
iptables -t mangle -N proxypackets
iptables -t mangle -A proxypackets -j MARK --set-mark 120
iptables -t mangle -A proxypackets -j ACCEPT
# Такие пакеты можно выделять с помощью критерия socket
iptables -t mangle -I PREROUTING -m socket -j proxypackets

Таким образом, пакеты, перехваченные TPROXY-правилом, маркируются и направляются на локальный сокет (порт 3129), который должен прослушиваться специально сконфигурированным прокси-сервером (в случае Squid, в файл конфигурации squid.conf нужно добавить строку http_port 3129 tproxy). Все пакеты, принадлежащие уже проксируемым соединениям, перехватываются правилом с критерием socket (этот критерий позволяет определить, существует ли на нашем хосте сокет, связанный с данным пакетом), маркируются и немедленно пропускаются. Отметим, что последнее правило будет обрабатываться раньше, чем правило с TPROXY, так как параметр -I обеспечивает вставку правил в начало цепочки, и при последовательном добавлении нескольких правил с этим параметром, порядок добавленных правил будет обратным порядку их ввода.

Таблица nat

Предназначена для операций stateful-преобразования сетевых адресов и портов обрабатываемых пакетов.

Цепочки

Таблица nat содержит следующие цепочки:

PREROUTING — в эту цепочку пакеты попадают до принятия решения о маршрутизации. По сути, термин «решение о маршрутизации» подразумевает деление трафика на входящий (предназначенный самому хосту) и транзитный (идущий через этот хост на другие хосты). Именно на данном этапе нужно проводить операции проброса (DNAT, REDIRECT, NETMAP).
OUTPUT — через эту цепочку проходят пакеты, сгенерированные процессами самого хоста. На данном этапе при необходимости можно повторить операции проброса, так локально сгенерированные пакеты не проходят цепочку PREROUTING и не обрабатываются ее правилами. См. пример для действия DNAT ниже.
POSTROUTING — через эту цепочку проходят все исходящие пакеты, поэтому именно в ней целесообразно проводить операции маскарадинга (SNAT и MASQUERADE).

Действия

Допустимыми действиями в таблице nat являются:

MASQUERADE — подменяет адрес источника для исходящих пакетов адресом того интерфейса, с которого они исходят, то есть осуществляет маскарадинг. Такая операция позволяет, например, предоставлять доступ в Интернет целым локальным сетям через один шлюз.

Допустим, у нас есть локальная сеть 192.168.1.0/255.255.255.0 с несколькими компьютерами, имеющими адреса 192.168.1.2, 192.168.1.3 и т. д. Адрес 192.168.1.1 имеет внутренний (подключенный к локальной сети) сетевой интерфейс шлюза, назовем этот интерфейс eth1. Другой его интерфейс, назовем его eth0, подключен к сети Интернет и имеет адрес, допустим, 208.77.188.166. Тогда, чтобы обеспечить выход хостов из этой локальной сети в интернет, на шлюзе достаточно выполнить следующие команды

sysctl net.ipv4.ip_forward=1 # Разрешаем шлюзу передавать транзитный трафик
iptables -F FORWARD # На всякий случай очистим цепочку FORWARD
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Разрешаем проходить пакетам по уже установленным соединениям
iptables -A FORWARD -m conntrack --ctstate NEW -i eth1 -s 192.168.1.0/24 -j ACCEPT # Разрешаем исходящие соединения из локальной сети к интернет-хостам
iptables -P FORWARD DROP # Весь остальной транзитный трафик — запрещаем.
iptables -t nat -F POSTROUTING # На всякий случай очистим цепочку POSTROUTING таблицы nat
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # Маскарадим весь трафик, идущий через eth0

Теперь, если один из хостов локальной сети, например, 192.168.1.2, попытается связаться с одним из интернет-хостов, например, 204.152.191.37 (kernel.org), при проходе его пакетов через шлюз, их исходный адрес будет подменяться на внешний адрес шлюза, то есть 208.77.188.166. С точки зрения удаленного хоста (kernel.org), это будет выглядеть, как будто с ним связывается непосредственно сам шлюз. Когда же удаленный хост начнет ответную передачу данных, он будет адресовать их именно шлюзу, то есть 208.77.188.166. Однако, на шлюзе адрес назначения этих пакетов будет подменяться на 192.168.1.2, после чего пакеты будут передаваться настоящему получателю. Для такого обратного преобразования никаких дополнительных правил указывать не нужно — это будет делать все та же операция MASQUERADE. Простота трансляции сетевых адресов является одним из важнейших достоинств stateful-фильтрации.

Если же такой трансляции не производить, удаленный хост просто не сможет ответить на адрес 192.168.1.2, так как адресные пространства локальных сетей изолировано от адресного пространства Интернета. В мире могут существовать миллионы локальных сетей 192.168.1.0/255.255.255.0, и в каждой может быть свой хост 192.168.1.2. Эти сети могут и не быть связаны с Интернетом. Но если они с ним связаны — то только благодаря механизмам трансляции сетевых адресов.

SNAT (Source Network Address Translation) — работает аналогично MASQUERADE, однако позволяет указать адрес «внешнего» интерфейса (опция —to-source). Такой подход позволяет экономить процессорное время шлюза, так как в случае с MASQUERADE для каждого пакета адрес внешнего интерфейса определяется заново. Таким образом, если в предыдущем примере внешний адрес шлюза 208.77.188.166 является статическим (то есть никогда не меняется), команду

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

целесообразно заменить на

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 208.77.188.166

Однако, в случае, если внешний адрес шлюза динамический, то есть меняется в начале каждой новой сессии, правильнее будет использовать именно MASQUERADE.

Дополнительно, если на внешнем интерфейсе шлюза «висит» несколько статических адресов, например, 208.77.188.166, 208.77.188.167 и 208.77.188.168, можно использовать балансировку между этими адресами:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 208.77.188.166-208.77.188.168

Теперь для каждого нового соединения адрес для подмены будет выбираться случайным образом.

DNAT (Destination Network Address Translation) — подменяет адрес назначения для входящих пакетов, позволяя «пробрасывать» адреса или отдельные порты внутрь локальной сети.

Возвращаясь к предыдущему примеру, предположим, что нам нужно «пробросить» внешний адрес шлюза 208.77.188.166 на хост 192.168.1.2, то есть все, кто будет обращаться по внешнему адресу шлюза 208.77.188.166, должны попадать на хост 192.168.1.2. Это достигается следующими командами:

sysctl net.ipv4.ip_forward=1 # Разрешаем шлюзу передавать транзитный трафик
iptables -t nat -F PREROUTING # На всякий случай очистим цепочку PREROUTING таблицы nat
iptables -t nat -A PREROUTING -d 208.77.188.166 -j DNAT --to-destination 192.168.1.2 # Пробрасываем 208.77.188.166 на 192.168.1.2
iptables -F FORWARD # На всякий случай очистим цепочку FORWARD
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Разрешаем проходить пакетам по уже установленным соединениям
iptables -A FORWARD -m conntrack --ctstate NEW -d 192.168.1.2 -j ACCEPT # Разрешаем входящие соединения к 192.168.1.2
iptables -P FORWARD DROP # Весь остальной транзитный трафик — запрещаем.

В лучших традициях stateful-фаерволинга, подменяются не только адреса назначения для входящих пакетов (208.77.188.166 -> 192.168.1.2), но и адреса источника для исходящих пакетов (192.168.1.2 -> 208.77.188.166), поэтому для интернет-хостов создается полное впечатление, что они общаются именно с 208.77.188.166.

Однако, при всей своей простоте и наглядности, этот пример имеет два недостатка. Во-первых, из нашей локальной сети 192.168.1.0/24 адрес 208.77.188.166 может быть недоступен, так как 192.168.1.2, увидев, что запрос исходит из его сети, может отправить ответ непосредственно отправителю (например, 192.168.1.3), минуя сам шлюз. Отправитель же будет ждать ответа от 208.77.188.166, и просто проигнорирует ответ от 192.168.1.2. Впрочем, эта проблема легко исправляется добавлением SNAT’а для пробрасываемых пакетов:

iptables -t nat -A POSTROUTING -d 192.168.1.2 -s 192.168.1.0/24 -j SNAT --to-source 192.168.1.1

Теперь, с точки зрения 192.168.1.2, к нему будет обращаться только сам шлюз (192.168.1.1), поэтому ответ также пойдет через шлюз, где будет корректно оттранслирован. Такое решение тоже имеет недостаток — подмена исходного адреса пакета приводит к тому, что компьютер, на который мы пробрасываем соединение, не может определить реального инициатора соединения. Чтобы уменьшить «вредность» этого правила, в него добавлена опция «-s 192.168.1.0/24», которая ограничивает применение этого правила только пакетами из локальной сети. Таким образом, соединения из локальной сети будут выглядеть как соединения, инициированные шлюзом, а соединения из внешней сети будут иметь свои оригинальные адреса.

Вторым недостатком предложенного примера является некорректная обработка запросов с самого шлюза. Ведь пакеты, генерируемые локальными процессами, не проходят цепочку PREROUTING. Поэтому правило DNAT нужно также добавить и в цепочку OUTPUT таблицы nat:

iptables -t nat -A OUTPUT -d 208.77.188.166 -j DNAT --to-destination 192.168.1.2

Разумеется, исходящие соединения к 192.168.1.2 и ответы на них должны быть разрешены соответственно в цепочках OUTPUT и INPUT таблицы filter. Самый простой способ сделать это —

iptables -F INPUT # Очищаем цепочку INPUT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Разрешаем входящие пакеты по уже установленным соединениям
iptables -P INPUT DROP # Все остальные входящие пакеты — запрещаем
iptables -F OUTPUT # Очищаем цепочку OUTPUT
iptables -P OUTPUT ACCEPT # Разрешаем исходящие пакеты безо всяких ограничений

Кроме того, при помощи действия DNAT можно пробрасывать не только сразу весь IP-адрес, но и отдельные TCP- или UDP-порты. Например, если в предыдущем примере мы в каждое из правил

iptables -t nat -A PREROUTING -d 208.77.188.166 -j DNAT --to-destination 192.168.1.2
iptables -t nat -A POSTROUTING -d 192.168.1.2 -s 192.168.1.0/24 -j SNAT --to-source 192.168.1.1
iptables -t nat -A OUTPUT -d 208.77.188.166 -j DNAT --to-destination 192.168.1.2

добавим

то мы «пробросим» не сам адрес 208.77.188.166, а только его TCP-порт 80 (HTTP). Обращения на все остальные TCP- и UDP-порты, а также ICMP-пакеты, поступившие на адрес 208.77.188.166, будут обрабатываться шлюзом, и лишь входящие TCP-соединения на порт 80 будут передаваться на 192.168.1.2.

Как и SNAT, DNAT поддерживает указание диапазонов адресов для подмены. Таким образом можно, например, балансировать нагрузку между несколькими серверами.

REDIRECT — подменяет номер порта в TCP- или UDP-пакете, а также подменяет адрес назначения на свой собственный. Например,

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080

позволяет «завернуть» все исходящие из локальной сети TCP-соединения на порт 80, на TCP-порт 8080 шлюза. Если этот порт обслуживается специально настроенным прокси-сервером, то можно организовать «прозрачное проксирование» — клиенты из локальной сети даже не будут подозревать, что их запросы идут через прокси-сервер. Разумеется, входящие соединения из локалки на TCP-порт 8080 должны быть разрешены в таблице filter.

Другой полезный пример:

iptables -t nat -A PREROUTING -i eth0 -s 213.180.0.0/16 -p tcp --dport 80 -j REDIRECT --to-port 8000

«заворачивает» все входящие из Интернета, а точнее подсети 213.180.0.0/255.255.0.0 TCP-соединения на порт 80, переадресуя их на порт 8000 того же сервера (где, например, может работать специальный веб-сервер). Как обычно, входящие соединения на TCP-порт 8000 должны быть разрешены в таблице filter.

SAME — в зависимости от цепочки (PREROUTING или POSTROUTING) может работать как DNAT или SNAT. Однако, при указании (в параметре —to-ip) одного или нескольких диапазонов IP-адресов, определяет для каждого нового соединения подставляемый адрес не случайно, а базируясь на IP-адресе клиента. Таким образом, адрес для подмены остается постоянным для одного и того же клиента при повторных соединениях (что не выполняется для обычных DNAT/SNAT). В некоторых случаях это бывает важным.

NETMAP — позволяет «пробросить» целую сеть. Например, для шлюза, стоящего между сетями 192.168.1.0/24 и 192.168.2.0/24 можно организовать следующий проброс:

iptables -t nat -A PREROUTING -s 192.168.1.0/24 -d 192.168.3.0/24 -j NETMAP --to 192.168.2/24

Теперь, при обращении, например, хоста 192.168.1.3 на IP-адрес 192.168.3.2 он будет попадать на 192.168.2.2 (при условии, что такой транзитный трафик разрешен на шлюзе в цепочке FORWARD таблицы filter, а также на хостах сети 192.168.1.0/24 наш шлюз прописан в качестве шлюза для подсети 192.168.3.0/24).

Примечание: следующее действие планируется к переносу в еще не написанный раздел статьи (Устаревшие критерии и действия).

MIRROR — довольно интересная игрушка. Меняет местами адрес источника и назначения и высылает пакет обратно. Создано исключительно для демонстрационных целей. Однако, может, например, применяться для защиты от сканирования портов — в результате атакующий сканирует свои собственные порты. Однако наличие двух встречных MIRROR’ов на двух хостах может повлечь бесконечное блуждание одних и тех же пакетов, забивающее канал. Поэтому применяйте это действие с осторожностью.

Таблица filter

Предназначена для фильтрации трафика, то есть разрешения и запрещения пакетов и соединений.

Цепочки

Таблица filter содержит следующие цепочки:

INPUT — эта цепочка обрабатывает трафик, поступающий непосредственно самому хосту.
FORWARD — позволяет фильтровать транзитный трафик.
OUTPUT — эта цепочка позволяет фильтровать трафик, исходящий от самого хоста.

Действия

Допустимыми действиями в таблице filter являются:

ACCEPT — пропуск пакета. Пакет покидает текущую базовую цепочку и следует дальше по потоковой диаграмме (см. рис.).
REJECT — заблокировать пакет и сообщить его источнику об отказе. По умолчанию об отказе сообщается отправкой ответного ICMP-пакета «icmp-port-unreachable». Однако, это действие поддерживает опцию —reject-with, позволяющую указать формулировку сообщения об отказе (возможные значения: icmp-net-unreachable, icmp-host-unreachable, icmp-proto-unreachable, icmp-net-prohibited, icmp-host-prohibited). Для протокола TCP поддеживается отказ в форме отправки RST-пакета (—reject-with tcp-reset).
DROP — заблокировать пакет, не сообщая источнику об отказе. Более предпочтительна при фильтрации трафика на интерфейсах, подключенных к интернету, так как понижает информативность сканирования портов хоста злоумышленниками.

Также определенный интерес представляют действия, предоставляемые модулями xtables-addons (в настоящее время этот проект уже включен в Debian testing). Некоторые из них:

STEAL — аналогично DROP, но в случае использования в цепочке OUTPUT при блокировании исходящего пакета не сообщает об ошибке приложению, пытавшемуся отправить этот пакет.
TARPIT — «подвесить» TCP-соединение. Используется лишь в самых крайних случаях, например, при борьбе с DoS-атаками. Отвечает на входящее соединение, после чего уменьшает размер фрейма до нуля, блокируя возможность передачи данных. Соединение будет «висеть» в таком состоянии пока не истечет тайм-аут на атакующей стороне (обычно 20—30 минут). При этом на такое соединение расходуются системные ресурсы атакующей стороны (процессорное время и оперативная память), что может быть весьма ощутимо при значительном количестве соединений. В случае правильного использования действия TARPIT ресурсы атакуемой стороны практически не расходуются.

Под правильным применением понимается предотвращение обработки таких соединений подсистемой conntrack, так как в противном случае будут расходоваться системные ресурсы самого атакуемого хоста. Например, перед добавлением правила блокирования порта

iptables -I INPUT -p tcp --dport 25 -j TARPIT

обязательно добавляйте в таблицу raw соответствующее правило

iptables -t raw -I PREROUTING -p tcp --dport 25 -j NOTRACK

предотвращающее обработку блокируемых соединений подсистемой conntrack.

DELUDE — создать видимость открытого TCP-порта. На SYN-пакеты отвечает пакетами SYN/ACK, на все прочие пакеты отвечает RST. Очень полезно для введения в заблуждение злоумышленника, сканирующего порты вашего хоста.
CHAOS — для каждого нового TCP-соединения случайно выбрать одно из двух действий. Первое из них — REJECT, второе, в зависимости от выбранной опции, либо TARPIT (—tarpit), либо DELUDE (—delude). В частности, при использовании действия CHAOS —delude для всех неиспользуемых портов, сканирующий ваши порты злоумышленник получит совершенно неверную информацию о состоянии ваших портов. В случае с CHAOS —tarpit ситуация усугубится еще и «подвисающими» соединениями.

Особо заметим, что все действия, перечисленные в качестве допустимых в таблице filter, можно применять в любой из цепочек любой из таблиц (конечно, с разумными ограничениями — например, не стоит ставить действия TARPIT, CHAOS и DELUDE для собственных исходящих пакетов). Однако эти действия предназначены именно для фильтрации, и применение их за пределами таблицы filter является дурным тоном. Как и, например, применение действий, специфичных для таблицы mangle, в таблицах filter и nat.

Таблица security

Предназначена для изменения маркировки безопасности (меток SELinux) пакетов и соединений.

Цепочки

Аналогичны цепочкам таблицы filter:

INPUT — эта цепочка обрабатывает трафик, поступающий непосредственно самому хосту.
FORWARD — через эту цепочку проходит транзитный трафик.
OUTPUT — эта цепочка позволяет обрабатывать трафик, исходящий от самого хоста.

Так как эта таблица появилась относительно недавно, ее редко можно увидеть на схемах следования пакетов через цепочки и таблицы netfilter’а. Поэтому стоит отметить, что все цепочки таблицы security пакеты проходят непосредственно после одноименных цепочек таблицы filter.

Действия

Данная таблица добавлена в ядро Linux в версии 2.6.27. Ранее операции с метками безопасности выполнялись в таблице mangle, и в целях обратной совместимости все действия, разрешенные для таблицы security, можно использовать и в таблице mangle.

SECMARK — устанавливает для пакета контекст безопасности SELinux (единственная допустимая опция —selctx).
CONNSECMARK — позволяет скопировать контекст безопасности SELinux с отдельного пакета на соединение в целом (опция —save) и наоборот (опция —restore).

Таблица raw

Предназначена для выполнения действий с пакетами до их обработки системой conntrack.

Обратите внимание, что в данной таблице не будут срабатывать критерии, которым для корректной работы необходим conntrack (это критерии conntrack, connmark, connlimit, connbytes).

Цепочки

PREROUTING — в эту цепочку входящие пакеты попадают раньше, чем в любую другую из цепочек iptables, и до обработки их системой conntrack.
OUTPUT — аналогично для пакетов, сгенерированных самим хостом.

Действия

NOTRACK — позволяет предотвратить обработку пакетов системой conntrack. Разумеется, применять его стоит не ко всем пакетам подряд, а только к тем, для которых такая обработка не нужна и даже вредна. Например, к пакетам, к которым впоследствии применяется действие TARPIT (см. выше).
CT — более функциональный инструмент, добавленный в версии Linux 2.6.34. Позволяет задать различные настройки conntrack, в соответствии с которыми будет обрабатываться соединение, открытое данным пакетом. В частности, можно:

Отключить отслеживание соединения (опция —notrack). Таким образом, функциональность действия CT включает и функциональность NOTRACK, так что, возможно, действие NOTRACK будет объявлено устаревшим.
Задать вспомогательный модуль (conntrack helper) для данного соединения. Если раньше указать нестандартные порты для такого модуля можно было только в параметрах его загрузки (/etc/modprobe.conf или /etc/modprobe.d/netfilter.conf, например, options nf_conntrack_ftp ports=2121), то теперь это можно сделать и через правила netfilter:

iptables -t raw -I PREROUTING -p tcp --dport 2121 -j CT --helper ftp

Ограничить список событий conntrack, которые будут генерироваться для данного соединения. Например, правило

iptables -t raw -I PREROUTING -p tcp --dport 8000 -j CT --ctevents new,destroy

будет предписывать для всех соединений на TCP-порт 8000 генерировать только события «открытие соединения» (NEW) и «завершение соединения» (DESTROY), игнорируя все прочие события. Полный список возможных событий: new, related, destroy, reply, assured, protoinfo, helper, mark, natseqinfo, secmark.

Задать зону conntrack для данного пакета (параметр —zone). Механизм зон conntrack позволяет корректно отслеживать, фильтровать и NAT’ить соединения даже в том случае, если хост подключен к нескольким сетям, использующим одинаковые пространства имен, через различные интерфейсы (например, интерфейсы eth0 и eth1 подключены к двум разным сетям, но обе эти сети используют пространство 192.168.0.0/24). Традиционно, для идентификации соединений conntrack использует кортежи (tuples) — набор значений в который входят адреса и порты (в случае ICMP — типы и коды ICMP) источника и назначения при передаче данных в прямом и обратном направлении. Очевидно, что при наличии нескольких подсетей с одинаковыми адресными пространствами, возможно возникновение путаницы, когда сразу нескольким соединениям ставится в соответствие одна и та же запись в таблице соединений. Чтобы избежать такой ситуации, в кортеж был добавлен идентификатор зоны conntrack — целое число, которое можно устанавливать через специальное правило в таблице raw в зависимости от входящего/исходящего интерфейса (как уже говорилось выше, цепочки таблицы raw пакеты проходят еще до обработки их conntrack’ом). Например,

iptables -t raw -I PREROUTING -i eth1 -j CT --zone 1
iptables -t raw -I OUTPUT -o eth1 -j CT --zone 1

Таким образом, пакеты, входящие или исходящие через интерфейс eth1, будут получать идентификатор зоны 1, в то время как пакеты интерфейса eth0 будут по-прежнему использовать зону по умолчанию (идентификатор 0), и путаницы не произойдет.

Кроме того, идентификатор зоны можно задать для каждого интерфейса через sysfs, минуя iptables (псевдофайл /sys/class/net/имя_интерфейса/nf_ct_zone):

echo 1 > /sys/class/net/eth1/nf_ct_zone

Однако, стоит заметить, что iptables/netfilter позволяют реализовать более гибкую логику управления идентификатором зоны, опирающуюся на различные параметры пакетов, и поэтом данный параметр действия CT может быть полезен при решении различных сложных задач управления трафиком при использовании зон conntrack.

RAWDNAT — позволяет выполнять «проброс» адресов и портов «сырым» методом — без использования системы conntrack, то есть без учета состояний соединений. Это действие реализовано в рамках проекта xtables-addons. Применять его можно только в таблице raw. Имеет единственную опцию —to-destination адрес[/маска], по смыслу аналогичную опции —to действия NETMAP, то есть при указании маски заменяются только те биты в адресе, которые соответствуют единичным битам маски. Биты адреса, соответствующие нулевым битам маски, остаются неизменными. При отсутствии маски изменяется весь адрес.

Отметим, что в отличие от действий таблицы nat, которые работают только с соединениями в целом, операции «сырого» преобразования адресов работают только с отдельными пакетами, никак не учитывая контекст их передачи. Вышесказанное можно проиллюстрировать, скажем, таким простым примером: для элементарной операции «проброса» внешнего адреса на другой адрес при использовании обычных операций NAT достаточно одного правила^[4]

iptables -t nat -A PREROUTING -i eth0 -d 212.201.100.135 -j  DNAT --to-destination 199.181.132.250

в то время как для той же операции при использовании «сырых» преобразований необходимо минимум два правила

iptables -t raw -A PREROUTING -i eth0 -d 212.201.100.135 -j  RAWDNAT --to-destination 199.181.132.250
iptables -t rawpost -A POSTROUTING -o eth0 -s 199.181.132.250 -j RAWSNAT --to-source 212.201.100.135

Как уже говорилось выше, при использовании обычной операции DNAT в ответных пакетах, приходящих с пробрасываемого адреса (199.181.132.250), производится автоматическая (без необходимости писать для этого отдельные правила) подмена исходного адреса на изначальный (212.201.100.135), и обращающиеся по адресу 212.201.100.135 хосты даже не подозревают, что общаются с кем-то другим. В случае же «сырого» преобразования такая автоматическая обработка невозможна, так как она требует возможности проверять пакеты на принадлежность соединению. С другой стороны, операции «сырого» преобразования являются более гибким инструментом, а также могут работать даже с UNTRACKED и INVALID-пакетами.

Таблица rawpost

Данная таблица предназначена для выполнения операций «сырого» преобразования адресов (без использования информации о соединениях), которые не могут быть реализованы в рамках таблицы raw, а именно, для операции «сырой» подмены исходного адреса (маскарадинга).

Как и в таблице raw, в rawpost отсутствует возможность обращения к conntrack, поэтому критерии, использующие эту подсистему (conntrack, connmark, connlimit, connbytes), в этой таблице работать не будут.

Данная таблица реализована в рамках проекта xtables-addons и отсутствует в стандартном комплекте iptables/netfilter.

Цепочки

POSTROUTING — обрабатывает весь исходящий трафик.

Действия

В таблице rawpost можно использовать действие RAWSNAT, выполняющее операцию «сырой» подмены исходного адреса. Имеет единственную опцию —to-source адрес[/маска], позволяющую задать новый исходный адрес для обрабатываемых пакетов. Как обычно, при наличии маски, в обрабатываемых адресах изменяются только те биты, которые в маске установлены в единицу, при отсутствии маски адрес изменяется целиком. Например, если по правилу

iptables -t rawpost -A POSTROUTING -o eth0 -s 10.125.0.0/16 -d 172.18.1.100 -j RAWSNAT --to-source 192.168.0.20/16

будет обработан пакет с исходным адресом 10.125.32.28, то этот адрес будет заменен на 192.168.32.28.

Если же при задании правила маску /16 в параметре —to-source опустить, адрес будет заменен на 192.168.0.20. Но так лучше не делать, потому что мы выполняем трансляцию для всех пакетов из подсети 10.125.0.0/16, и без отслеживания соединений не сможем отличить, какие пакеты следует вернуть 10.125.32.28, а какие — другим хостам из этой подсети. Сама же операция «возвращения» пакетов требует отдельного RAWDNAT-правила:

iptables -t raw -A PREROUTING -i eth0 -s 172.18.1.100 -d 192.168.0.0/16 -j RAWDNAT --to-destination 10.125.0.0/16

которое выполняет обратную подмену, заменяя адреса назначения в пакетах-ответах. Таким образом, хост 172.18.1.100 будет считать, что к нему обращаются хосты из подести 192.168.0.0/16, а вовсе не из 10.125.0.0/16.

Для сравнения, с использованием stateful-преобразования достаточно одного правила

iptables -t nat -A POSTROUTING -o eth0 -s 10.125.0.0/16 -d 172.18.1.100 -j NETMAP --to 192.168.0.0/16

которое будет обеспечивать все необходимые преобразования адресов.

Заметим, что для корректной работы обеих описанных конфигураций требуется, чтобы хост 172.18.1.100, а также маршрутизаторы на пути от нашего хоста к нему, считали наш хост шлюзом для сети 192.168.0.0/16.

Критерии

Напоминаем, критерий — это логическое выражение, определяющее, соответствует ли пакет или соединение данному конкретному правилу.

В одном правиле можно указать несколько критериев. Для того, чтобы пакет был обработан правилом, должны выполняться все критерии, то есть критерии неявно объединяются логическим AND.

Также многие критерии и параметры критериев можно инвертировать, поставив перед ними восклицательный знак. В описании синтаксиса таких критериев присутствует пометка «[!]». Инверсия меняет смысл критерия или его параметра на ровно противоположный. Например, критерию -s 127.0.0.1 соответствуют все пакеты, имеющие обратный адрес 127.0.0.1, а критерию ! -s 127.0.0.1 — все пакеты, кроме имеющих обратный адрес 127.0.0.1. В ранних версиях iptables восклицательный знак можно было ставить между названием критерия и значением, например, -s ! 127.0.0.1, однако последние версии iptables (в частности, 1.4.3.2 и выше), уже не поддерживают этот синтаксис, выдавая следующую ошибку:

Using intrapositioned negation (`--option ! this`) is deprecated in favor of extrapositioned (`! --option this`).

Далее мы кратко рассмотрим наиболее важные и интересные критерии.

Универсальные критерии

Под этим термином понимаются критерии, применимые ко все пакетам и соединениям, независимо от протокола транспортного уровня, и не требующие подключения внешних модулей (-m).

[!] -p, —protocol протокол

Позволяет указать протокол транспортного уровня. Наиболее часто употребляются tcp, udp, icmp и all. Протокол также можно указать с помощью номера или названия согласно перечню, приведенному в /etc/protocols. Значение «любой протокол» можно указать с помощью слова all или числа 0. Если протокол не указан, подразумевается «любой протокол».

При указании протокола становится возможным использовать специфичные для него критерии. Например, для TCP и UDP доступны критерии —sport и —dport, для ICMP — —icmp-type. Подробнее эти критерии будут рассмотрены ниже.

[!] -s, —src, —source адрес[/маска][,адрес[/маска]…]

Определяет адрес отправителя. В качестве адреса может выступать IP-адрес (возможно с маской), имя хоста из /etc/hosts, или доменное имя (в последних двух случаях перед добавлением правила в цепочку имя резольвится в IP-адрес). Маска подсети может быть указана в классическом формате (например, 255.255.0.0) либо в формате CIDR (например, 16)^[5]. Например,

iptables -I INPUT -i eth0 -s 192.168.0.0/16 -j DROP

(где eth0 — интерфейс, подключенный к интернету), позволяет заблокировать простейший вид спуфинга — из интернета не могут приходить пакеты с обратным адресом, принадлежащим к диапазону, зарезервированному для локальных сетей.

Начиная с версии iptables 1.4.6, в одном параметре -s можно указывать более одного адреса, разделяя адреса запятой. При этом для каждого адреса будет добавлено отдельное правило. Например, запись

iptables -A INPUT -i eth0 -s 192.168.0.0/16,172.16.0.0/12,10.0.0.0/8 -j DROP

эквивалентна записи

iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP
iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j DROP
iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP

При добавлении через команду -A (вставка в конец цепочки) порядок добавляемых правил будет соответствовать порядку перечисления адресов в исходной команде, при использовании команды -I (вставка в начало цепочки либо после заданного правила) порядок будет обратным исходному.

Настойчиво не рекомендуется использовать доменные имена, для разрешения (резольва) которых требуются DNS-запросы, так как на этапе конфигурирования фаервола DNS может работать некорректно. Также, заметим, имена резольвятся всего один раз — при добавлении правила в цепочку. Впоследствии соответствующий этому имени IP-адрес может измениться, но на уже записанные правила это никак не повлияет (в них останется старый адрес). Если указать доменное имя, которое резольвится в несколько IP-адресов, то для каждого адреса будет добавлено отдельное правило (как и в случае перечисления нескольких адресов, см. выше).

[!] -d, —dst, —destination адрес[/маска][,адрес[/маска]…]

Определяет адрес получателя. Синтаксис аналогичен -s.

Заметим, что, если использовать возможность указания нескольких адресов (перечислив их явно или указав доменное имя, резольвящееся на несколько адресов) одновременно в параметрах -s и -d, то на каждое возможное сочетание адресов будет добавлено свое правило. Например, запись

iptables -A FORWARD -s 192.168.1.1,192.168.1.2 -d 192.168.1.3,192.168.1.4 -j REJECT

эквивалентна

iptables -A FORWARD -s 192.168.1.1 -d 192.168.1.3 -j REJECT
iptables -A FORWARD -s 192.168.1.1 -d 192.168.1.4 -j REJECT
iptables -A FORWARD -s 192.168.1.2 -d 192.168.1.3 -j REJECT
iptables -A FORWARD -s 192.168.1.2 -d 192.168.1.4 -j REJECT

[!] -i, —in-interface имя_интерфейса

Определяет входящий сетевой интерфейс. Если указанное имя интерфейса заканчивается знаком «+» (например, tun+), то критерию соответствуют все интерфейсы, чьи названия начинаются на указанное имя (для нашего примера tun0, tun1, …). Данный критерий можно использовать в цепочках PREROUTING, INPUT и FORWARD. Например,

iptables -I INPUT -i lo -j ACCEPT

позволит принимать весь трафик, входящий через интерфейс обратной петли.

[!] -o, —out-interface имя_интерфейса

Определяет исходящий сетевой интерфейс. Синтаксис аналогичен -i. Критерий можно использовать в цепочках FORWARD, OUTPUT и POSTROUTING. Вспоминая один из наших примеров,

iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE

будет маскарадить весь трафик, исходящий через интерфейс eth0.

Критерии, специфичные для протоколов

Протоколы транспортного уровня

TCP

[!] —sport, —source-port порт[:порт]

Позволяет указать исходящий порт (или их диапазон). Например,

iptables -I INPUT -m conntrack --ctstate NEW -p tcp --sport 0:1023 -j DROP

заблокирует все входящие соединения с привилегированных портов (привилегированными в TCP/UDP считаются порты с 0 по 1023 включительно, так как для их использования нужны привилегии суперпользователя, и обычно такие порты используются демонами только в режиме прослушивания).

[!] —dport, —destination-port порт[:порт]

Позволяет указать порт назначения (или их диапазон). Синтаксис аналогичен —sport. Например,

iptables -I INPUT -p tcp --dport 80 -j ACCEPT

разрешит все входящие пакеты на 80 порт (HTTP).

[!] —tcp-flags маска установленные_флаги

Позволяет указать список установленных и снятых TCP-флагов. В маске перечисляются (через запятую, без пробелов) все проверяемые флаги, далее, после пробела, перечисляются (также через запятую) те из них, которые должны быть установлены. Все остальные перечисленные в маске флаги должны быть сняты. Возможные флаги: SYN ACK FIN RST URG PSH. Также можно использовать псевдофлаги ALL и NONE, обозначающие «все флаги» и «ни одного флага» соответственно.

Пример:

iptables -I INPUT -p tcp --tcp-flags SYN,RST,ACK,FIN SYN -j LOG --log-level DEBUG --log-prefix "TCP SYN: "

будет заносить в лог все входящие TCP SYN-пакеты. У обычного SYN-пакета всегда установлен флаг SYN и сняты флаги RST, ACK и FIN.

Другой пример:

iptables -I INPUT -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j REJECT --reject-with tcp-reset

будет препятствовать спуфингу от нашего имени. Ведь если мы получаем пакет с установленными флагами SYN и ACK (такой комбинацией флагов обладает только ответ на SYN-пакет) по еще не открытому соединению, это означает, что кто-то послал другому хосту SYN-пакет от нашего имени, и ответ пришел к нам. Конечно, злоумышленнику предстоит еще угадать номер последовательности, но лучше не предоставлять ему такого шанса. Согласно приведенному правилу, наш хост ответит RST-пакетом, после получения которого атакуемый хост закроет соединение. Добавление такого правила в конфигурацию фаервола настоятельно рекомендуется, потому что если злоумышленнику удастся осуществить спуфинг-атаку от вашего имени, при расследовании этого эпизода следы приведут к вам.

[!] —syn

Позволяет отлавливать TCP SYN-пакеты (сокращение для —tcp-flags SYN,RST,ACK,FIN SYN). Так что приведенный выше пример про логгирование SYN-пакетов можно записать в виде

iptables -I INPUT -p tcp --syn -j LOG --log-level DEBUG --log-prefix "TCP SYN: "

Более интересный пример:

iptables -I INPUT -m conntrack --ctstate NEW -p tcp ! --syn -j DROP

будет блокировать все попытки открыть входящее TCP-соединение не SYN-пакетом. Попытка установить соединение таким образом может быть либо ошибкой, либо атакой.

[!] —tcp-option номер

Позволяет проверить, установлена ли в заголовке TCP-пакета соответствующая опция. Полный список опций с их номерами представлен на сайте IANA.

UDP

[!] —sport, —source-port порт[:порт]

Позволяет указать исходящий порт (или их диапазон). Синтаксис и принцип работы аналогичен описанной выше одноименной опции TCP.

[!] —dport, —destination-port порт[:порт]

Позволяет указать входящий порт (или их диапазон). Синтаксис и принцип работы аналогичен описанной выше одноименной опции TCP.

SCTP

[!] —sport, —source-port порт[:порт]

[!] —dport, —destination-port порт[:порт]

[!] —chunk-types {all|any|only} тип_секции[:флаги][,тип_секции[:флаги]…]

Позволяет анализировать набор секций (chunks), входящих в состав SCTP-пакета. Возможные типы секций: DATA INIT INIT_ACK SACK HEARTBEAT HEARTBEAT_ACK ABORT SHUTDOWN SHUTDOWN_ACK ERROR COOKIE_ECHO COOKIE_ACK ECN_ECNE ECN_CWR SHUTDOWN_COMPLETE ASCONF ASCONF_ACK. Также, для секций, имеющих флаги (DATA, ABORT и SHUTDOWN_COMPLETE) можно проверить состояние флагов, указав соответствующие буквы после названия секции (для DATA — U, B и E, для ABORT и SHUTDOWN_COMPLETE — T). Литера в верхнем регистре предполагает установленный флаг, в нижнем — снятый. Ключевое слово в начале позволяет определить логику работы: в случае all должны присутствовать все перечисленные секции, для any — хотя бы одна из них, для only — пакет должен состоять только из перечисленных секций. Примеры:

iptables -I INPUT -p sctp --chunk-types only DATA,INIT -j DROP

заблокирует все входящие SCTP-пакеты, состоящие только из секций DATA и INIT, а

iptables -I INPUT -p sctp --chunk-types any DATA:Be -j ACCEPT

разрешит входящие SCTP-пакеты, содержащие секцию DATA с установленным флагом B и снятым флагом E, то есть первый фрагмент фрагментированной DATA-секции.

DCCP

[!] —sport, —source-port порт[:порт]

[!] —dport, —destination-port порт[:порт]

[!] —dccp-types маска

Позволяет указать тип DCCP-пакета. В маске через запятую перечисляются DCCP-типы (допустимые названия: REQUEST RESPONSE DATA ACK DATAACK CLOSEREQ CLOSE RESET SYNC SYNCACK INVALID). Пакет считается удовлетворяющим критерию, если имеет один из типов, перечисленных в маске. Например,

iptables -I INPUT -p dccp --dccp-types RESET,INVALID -j LOG --log-level DEBUG --log-prefix "DCCP RESET or INVALID: "

занесет в лог все входящие RESET и INVALID DCCP-пакеты.

UDP Lite

Поддержка специфических опций протокола UDPLite (а именно, проверки портов источника и/или назначения) в netfilter реализована не вполне очевидным образом: через критерий multiport (см. раздел вспомогательные критерии).

Если для обычного UDP соответствие номера порта проверялось выражением вида -p udp —dport номер_порта (или -p udp —sport номер_порта), то в случае UDPLite аналогичное выражение будет выглядеть как -p udplite -m multiport —dports номер_порта (или -p udplite -m multiport —sports номер_порта). Все опции критерия multiport для UDPLite поддерживаются в полном объеме.

IPv4

Ниже перечислены критерии, которые реализованы только для протокола IPv4 и, соответственно, могут быть вызваны только через iptables, но не через ip6tables.

[!] -f, —fragment

Проверка фрагментации: критерию соответствуют только фрагменты пакета, начиная со второго фрагмента. Пример:

iptables -I INPUT -p icmp -f -j DROP

блокирует фрагменты ICMP-пакетов. Так как, в силу функционального назначения протокола, ICMP-пакеты должны быть очень небольшими и нормально укладываться в MTU, наличие их фрагментов обычно свидетельствует об ошибке или попытке атаки.

У второго и последующего фрагментов нет заголовка транспортного уровня, поэтому бессмысленно пытаться использовать для них критерии номеров TCP/UDP-портов или типа ICMP.

addrtype — позволяет проверить тип адреса источника и/или назначения с точки зрения подсистемы маршрутизации сетевого стека ядра. Допустимые типы адресов: UNSPEC (адрес 0.0.0.0), UNICAST, LOCAL (адрес принадлежит нашему хосту), BROADCAST, ANYCAST, MULTICAST, BLACKHOLE, UNREACHABLE, PROHIBIT, THROW, NAT, XRESOLVE. Подробнее о большинстве перечисленных типов адресов и их использовании в Linux (точнее, в подсистеме iproute2) можно почитать здесь. Данный критерий поддерживает следующие параметры:

[!] —src-type тип[,тип…] — проверка, принадлежит ли исходный адрес пакета одному из перечисленных типов.

[!] —dst-type тип[,тип…] — проверка, принадлежит ли адрес назначения пакета одному из перечисленных типов.

—limit-iface-in — ограничивает проверку типа адреса только записями для интерфейса, через который пакет вошел на хост. Допускается использовать этот параметр только в цепочках PREROUTING, INPUT и FORWARD.

—limit-iface-out — ограничивает проверку типа адреса только записями для интерфейса, через который пакет вошел на хост. Допускается использовать этот параметр только в цепочках POSTROUTING, OUTPUT и FORWARD.

Критерии —limit-iface-in и —limit-iface-out нельзя указывать одновременно.

В качестве практического примера использования данного критерия можно привести простейшую защиту от спуфинга:

iptables -I INPUT -m addrtype --src-type LOCAL ! -i lo -j DROP

Это правило заблокирует пакеты, которые пришли с внешних интерфейсов, но при этом в качестве обратного адреса у них указан один из адресов, принадлежащих нашему хосту (например, 127.0.0.1).

ecn — позволяет проверять значения битов ECN в заголовках TCP и IPv4. Допустимые параметры:

[!] —ecn-tcp-cwr — проверка флага ECN CWR (Congestion Window Received) в TCP-заголовке пакета.

[!] —ecn-tcp-ece — проверка флага ECN ECE (ECN Echo) в TCP-заголовке пакета.

[!] —ecn-ip-ect значение — проверка значения, сформированного ECN-битами поля TOS (последние два бита). Возможные значения от 0 до 3.

realm — проверка области маршрутизации (realm) пакета. Имеет единственный параметр

[!] —realm значение[/маска], позволяющий указать численный идентификатор области. Если указана маска, то значение realm каждого проверяемого пакета сначала объединяется с маской при помощи побитового AND, а затем сравнивается со значением, указанным в правиле. Также вместо числа можно указать символьное название области согласно обозначениям в файле /etc/iproute2/rt_realms (в этом случае маску использовать нельзя).

ttl — обеспечивает проверку поля TTL в заголовке пакета. Позволяет установить, является ли значение TTL проверяемого пакета большим (—ttl-gt), меньшим (—ttl-lt), равным или не равным ([!] —ttl-eq) указанному значению.

ICMP

ICMP является протоколом контрольных сообщений IPv4. Несмотря на то, что ICMP формально является самостоятельным протоколом, и обращение к соответствующему критерию должно производиться с использованием синтаксиса для протокола (-p), а не для вспомогательного критерия (-m), де-факто этот протокол неотделим от IPv4, и поэтому соответствующий критерий может использоваться только в iptables, но не в ip6tables.

Критерий этого протокола имеет единственный параметр

[!] —icmp-type тип — обеспечивает проверку типа ICMP-пакета. Список возможных типов выводится по команде iptables -p icmp -h. Также можно указать стандартный числовой код. Например,

iptables -I INPUT -p icmp --icmp-type echo-request -j ACCEPT

как и аналогичное

iptables -I INPUT -p icmp --icmp-type 8 -j ACCEPT

пропустят все входящие ICMP-эхо-запросы (пинги).

IPv6

Ниже перечислены критерии, которые реализованы только для протокола IPv6 и, соответственно, могут быть вызваны только через ip6tables, но не через iptables.

Особо отметим, что критерии для некоторых подзаголовков IPv6 (dst, frag, hbh, rt) корректно вызываются только с использованием синтаксиса для расширенных критериев (ключ -m), хотя имеют номера протоколов в /etc/protocols и, формально, могут быть вызваны с использованием синтаксиса для протоколов (ключ -p) что, однако, является неверным. В таких случаях ip6tables выдает предупреждение вида

Warning: never matched protocol: ipv6-frag. use extension match instead.

гласящее, что в такое правило никогда не будет срабатывать. Если вы видите подобное предупреждение, удалите правило, которое его вызвало, и перепишите это правило с использованием корректного синтаксиса (-m).

С другими же критериями, которые представляют более или менее самостоятельные протоколы (ICMPv6, MH, IPSec AH и ESP), все ровно наоборот, и для них корректным будет использование именно синтаксиса протокола (ключ -p), а не расширенного критерия. Во избежание путаницы, такие критерии вынесены в отдельные подзаголовки, по аналогии с протоколами транспортного уровня (выше).

dst — проверят опции назначения (подзаголовок 60 Destination Options). Имеет две опции:

[!] —dst-len значение — проверяет длину подзаголовка;

[!] —dst-opts код[:длина][,код[:длина]…] — позволяет проверить вхождение в данный подзаголовок конкретных опций. Также можно проверить длину каждой из них. Можно указать до 16 опций (представленных числовыми кодами), разделяя их запятой.

eui64 — сравнивает младшие 64 бита исходного IPv6-адреса с битами исходного MAC-адреса, преобразованными согласно правилам автоконфигурирования IPv6-адресов на основании MAC-адресов. Таким образом, позволяет проверить, является ли IPv6-адрес отправителя пакета автоматически сконфигурированным (работает, если отправитель находится в одном широковещательном домене с нашим хостом, так как в противном случае сохранность MAC-адреса отправителя не может быть гарантирована).

frag — позволяет проверять параметры фрагментации (подзаголовок 44 Fragment). Допустимые опции:

[!] —fragid мин[:макс] — сверяет величину идентификатора фрагмента. Если указано одно значение, проверяется равенство, если указан диапазон — проверяется вхождение значения в этот диапазон (включая границы).

—fragres — проверяет, заполнены ли нулями зарезервированные поля заголовка (биты 29-30).

—fragfirst — проверяет, является ли данный фрагмент первым в последовательности.

—fraglast/—fragmore — проверяют M-флаг, показывающий, является ли данный фрагмент последним в последовательности (в этом случае —fraglast дает истину, а —fragmore ложь), или после него должны быть еще фрагменты (соответственно, наоборот). Эти две опции являются взаимоисключающими.

Также в документации можно найти упоминание параметра —fraglen , который якобы проверяет длину подзаголовка Fragment. Однако, согласно текущим соглашениям, длина этого подзаголовка фиксирована и равна 8 байтам, а названная опция ни на что не влияет.

hbh — проверяет опции Hop-by-Hop (подзаголовок 0 Hop-by-Hop). Синтаксис аналогичен параметру dst.

hl — обеспечивает проверку поля Hop Limit в IPv6-заголовке. Позволяет установить, является ли значение HL проверяемого пакета большим (—hl-gt), меньшим (—hl-lt), равным или не равным ([!] —hl-eq) указанному значению.

ipv6header — позволяет проверить наличие вспомогательных подзаголовков IPv6. Допустимыми типами заголовков являются: hop (hop-by-hop 0), dst (ipv6-opts 60), route (ipv6-route 43), frag (ipv6-frag 44), auth (ah 50), esp (esp 59). В скобках указаны «длинные» названия и числовые идентификаторы протокола. Используя опцию

[!] —header тип[,тип…]

вы можете указывать любые из этих обозначений — короткие названия, длинные названия или числовые идентификаторы. Отметим, что пакет будет соответствовать критерию в том случае, если будет содержать только перечисленные подзаголовки. Изменить это поведение можно, указав опцию —soft — в этом случае достаточно, чтобы пакет содержал хотя бы один из перечисленных подзаголовков.

rt — позволяет проверять параметры маршрутизации пакета (подзаголовок 43 Routing). Допустимые параметры:

[!] —rt-type тип — тип маршрутизации (0, 1 или 2);

[!] —rt-segsleft мин[:макс] — проверка значения поля Segment Left (показывает, сколько еще узлов должен пройти данный пакет, прежде чем достигнет цели);

[!] —rt-len значение — проверка длины всего подзаголовка.

Следующие три параметра работают для типа 0 (—rt-type 0):

—rt-0-res — проверять зарезервированные поля;

—rt-0-addrs адрес[,адрес…] — проверяет адреса, перечисленные в подзаголовке. Можно указать не более 16 адресов, разделяя их запятыми. Пакет считается удовлетворяющим критерию, если подзаголовок содержит все адреса, которые были перечислены в правиле, в том же порядке;

—rt-0-not-strict — делает условие проверки по предыдущем параметру не таким жестким: достаточно, чтобы хотя бы один из перечисленных адресов совпадал с соответствующим адресом в подзаголовке, при соблюдении порядка перечисления.

ICMPv6

ICMPv6 является протоколом контрольных сообщений IPv6. Несмотря на то, что ICMPv6 формально является самостоятельным протоколом, и обращение к соответствующему критерию должно производиться с использованием синтаксиса для протокола (-p), а не для вспомогательного критерия (-m), де-факто этот протокол неотделим от IPv6, и поэтому соответствующий критерий может использоваться только в ip6tables, но не в iptables.

Критерий этого протокола имеет единственный параметр

[!] —icmpv6-type тип

по смыслу и синтаксису аналогичный параметру —icmp-type критерия icmp (см. предыдущий раздел). Например,

ip6tables -I INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT

как и аналогичное

ip6tables -I INPUT -p icmpv6 --icmpv6-type 128 -j ACCEPT

пропустит входящие ICMPv6-эхо-запросы (пинги).

Как и в случае icmp, вы можете получить список допустимых типов сообщений, введя

MH

Критерий mh позволяет определять пакеты с подзаголовком IPv6 Mobility Header (RFC 3775). Как и в случае с ICMPv6, вызов данного критерия должен выполняться в соответствии с синтаксисом для протокола (через ключ -p). Имеет единственную опцию

[!] —mh-type мин[:макс]

позволяющую указать точное значение типа или диапазон допустимых значений. Перечень поддерживаемых типов MH можно получить, введя команду

Также к данному критерию допустимо обращение по названию ipv6-mh (-p ipv6-mh).

IPsec

netfilter «знает» два протокола из семейства IPsec: Authentication Header (-p ah) и Encapsulating Security Payload (-p esp).

AH

Для протокола AH поддерживается единственная опция

—ahspi значение[:значение] — позволяет указать значение (или диапазон значений) SPI (Security Parameter Index).

ESP

Протокол ESP имеет аналогичную по смыслу опцию

—espspi значение[:значение]

В большинстве конфигураций IPsec-пакеты просто пропускаются фаерволом (пусть с ними разбирается IPsec-подсистема):

iptables -I INPUT -p ah -j ACCEPT
iptables -I INPUT -p esp -j ACCEPT

Критерии состояния соединения

conntrack

Основной критерий, используемый для контроля состояния соединения. Он предоставляет эффективный набор инструментов, позволяющий использовать информацию системы conntrack о состоянии соединения. Затронутую тему весьма проблематично осветить в двух словах и привести по ней простые примеры, не выходя за краткий формат, принятый для нашей статьи. Поэтому ограничимся мы подробно рассмотрим лишь наиболее важный параметр данного критерия — ctstate. Для прочих параметров мы лишь кратко опишем синтаксис и назначение. За более подробной информацией обратитесь к документации, прилагаемой к вашему дистрибутиву. Итак,

[!] —ctstate маска

Маска содержит перечисление через запятую список возможных состояний соединения. Пакет считается удовлетворяющим критерию, если соединение, по которому он проходит, находится в одном из перечисленных состояний.

Возможные состояния:

NEW — соединение не открыто, то есть пакет является первым в соединении. Полезные примеры использования этого состояния приведены выше, в частности, при описании TCP-специфичных критериев.

ESTABLISHED — пакет относится к уже установленному соединению. Обычно такие пакеты принимаются без дополнительной фильтрации, как и в случае с RELATED.

RELATED — пакет открывает новое соединение, логически связанное с уже установленными, например, открытие канала данных в пассивном режиме FTP.

Например:

modprobe nf_conntrack_ftp # Подгружаем модуль для распознавания связанных FTP-соединений
# В старых системах этот модуль может называться ip_conntrack_ftp
iptables -F # Очищаем все цепочки таблицы filter
# Ко всем пакетам, которые относятся к уже установленным соединениям, применяем терминальное действие ACCEPT — пропустить
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 21 -j ACCEPT # Разрешаем открывать соединения на 21 TCP-порт.
iptables -P INPUT DROP # В качестве действия по умолчанию устанавливаем DROP — блокирование пакета
iptables -P OUTPUT ACCEPT # Разрешаем все исходящие пакеты

Этот набор команд обеспечит функционирование на хосте FTP-сервера с поддержкой как активного, так и пассивного режимов. В пассивном режиме FTP клиент сначала устанавливает управляющее соединение на TCP-порт 21 сервера. Когда возникнет необходимость передачи данных, клиент даст серверу команду PASV. Сервер выберет высокий порт и подключится к нему в режиме прослушивания, отправив номер порта клиенту по управляющему соединению. Система conntrack, при наличии подгруженного модуля ядра nf_conntrack_ftp, зафиксирует это сообщение и выделит номер порта. Когда клиент откроет соединение данных на этот высокий порт, система conntrack присвоит первому пакету статус RELATED, в результате чего пакет пройдет по нашему правилу и будет принят. Остальные пакеты в этом соединении будут иметь уже статус ESTABLISHED и тоже будут приняты.

Возможность корректно обрабатывать пассивный режим FTP, как это было описано выше, из всех unix-фаерволов доступна только в iptables. В других фаерволах для решения данной проблемы используются различные «костыли». Например, в pf управляющие FTP-соединения пропускаются через специальную программу ftp-proxy, которая анализирует трафик подобно conntrack и «на лету» добавляет правила для соединений данных. Однако даже подобные «костыли» существуют далеко не для всех протоколов. Поэтому можно утверждать, что в данном аспекте iptables находится вне конкуренции.

С обработкой активного режима таких проблем не возникает, так как сервер сам устанавливает соединение данных с порта 20, поэтому первый пакет пропускается согласно правилу по умолчанию цепочки OUTPUT. Правда, проблемы могут возникнуть на стороне фаервола клиента, но это уже не относится к компетенции сервера.

INVALID — пакет по смыслу должен принадлежать уже установленному соединению (например, ICMP-сообщение port-unreachable), однако такое соединение в системе не зарегистрировано. Обычно к таким пакетам применяют действие DROP:

iptables -I INPUT -m conntrack --ctstate INVALID -j DROP

UNTRACKED — отслеживание состояния соединения для данного пакета было отключено. Обычно оно отключается с помощью действия NOTRACK в таблице raw.

DNAT — показывает, что к данному соединению применена операция подмены адреса назначения (об операциях преобразования адресов см. выше).

SNAT — показывает, что к данному соединению применена операция подмены адреса источника (об операциях преобразования адресов см. выше).

Остальные параметры критерия conntrack, как уже говорилось, мы опишем лишь конспективно.

[!] —ctstatus маска

Применяется для определения статуса соединения в системе conntrack. Возможные статусы:

EXPECTED — данное соединение ожидалось системой conntrack по результатам анализа других соединений. Например, после того, как клиент и сервер через управляющее FTP-соединение согласуют номер порта для соединения данных в пассивном режиме, система conntrack на сервере будет ожидать входящее соединение на этот порт.
CONFIRMED — подтвержденное соединение. Такой статус присваивается соединению после того, как инициатор начал передачу пакетов.
SEEN_REPLY — соединение, по которому поступил ответ, то есть имеет место передача данных в обоих направлениях (поддержка данного состояния появилась сравнительно недавно).
ASSURED — соединение можно считать полностью установленным. Этот статус присваивается соединению после передачи определенного количества данных. Присвоение данного статуса приводит к увеличению conntrack-тайм-аута для данного соединения (эти тайм-ауты используются для определения и удаления «повисших» и оборванных соединений).
NONE — нет статуса. Соединение не соответствует ни одному из перечисленных критериев.

[!] —ctproto протокол

Протокол транспортного уровня, определенный системой conntrack. Синтаксис аналогичен стандартному критерию -p.

[!] —ctdir {ORIGINAL|REPLY}

Позволяет указать направление прохождения пакетов (ORIGINAL — от инициатора к отвечающему, REPLY — наоборот). Если не указывать эту опцию, под критерий будут подпадать пакеты, идущие в обоих направлениях.

[!] —ctorigsrc адрес[/маска], [!] —ctorigdst адрес[/маска], [!] —ctreplsrc адрес[/маска], [!] —ctrepldst адрес[/маска]

Позволяет определять адреса источника (src) и назначения (dst) при передаче данных от инициатора к отвечающему (orig) и наоборот (repl). Синтаксис аналогичен описанному выше стандартному критерию -s.

Обычно адрес-порт источника при передаче в прямом направлении совпадают с адресом-портом назначения при передаче в обратном направлении, и наоборот, адрес-порт источника при передаче в обратном направлении совпадает с адресом-портом назначения при передаче в прямом направлении. То есть, если клиент 192.168.1.2 обращается к серверу 192.168.1.1, то с точки зрения системы conntrack ситуация выглядит следующим образом:

→ В прямом направлении (от инициатора к отвечающему):

— Адрес источника (ctorigsrc): 192.168.1.2 (адрес клиента)

— Адрес назначения (ctorigdst): 192.168.1.1 (адрес сервера)

← В обратном направлении (от отвечающего к инициатору):

— Адрес источника (ctreplsrc): 192.168.1.1 (адрес сервера)

— Адрес назначения (ctrepldst): 192.168.1.2 (адрес клиента)

Однако для соединений, к которым применена трансляция адресов или портов, это может не выполняться. Например, рассмотрим ситуацию, когда клиент из нашей подсети (192.168.1.2) обращается к некоторому серверу в интернете (204.152.191.37) через наш сервер (внешний адрес нашего сервера 208.77.188.166, внутренний 192.168.1.1). Для корректной работы такой схемы нужно обеспечить на нашем сервере подмену исходного адреса (SNAT), например,

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 208.77.188.166

Тогда, с точки зрения системы conntrack нашего сервера,

→ В прямом направлении (от инициатора к отвечающему):

— Адрес источника (ctorigsrc): 192.168.1.2 (внутренний адрес клиента)

— Адрес назначения (ctorigdst): 204.152.191.37 (адрес интернет-сервера)

← В обратном направлении (от отвечающего к инициатору):

— Адрес источника (ctreplsrc): 204.152.191.37 (адрес интернет-севера)

— Адрес назначения (ctrepldst): 208.77.188.166 (внешний адрес нашего сервера)

В том случае, если адрес-порт источника при передаче в прямом направлении отличаются от адреса-порта назначения при передаче в обратном направлении, соединению будет присвоен статус SNAT.

Аналогично, если один из внешних адресов нашего сервера «проброшен» на внутренний сервер, например, так

iptables -t nat -A PREROUTING -d 208.77.188.166 -j DNAT --to-destination 192.168.1.2

то при обращении на этот адрес клиента извне (допустим, все тот же 204.152.191.37), получим

→ В прямом направлении (от инициатора к отвечающему):

— Адрес источника (ctorigsrc): 204.152.191.37 (адрес клиента)

— Адрес назначения (ctorigdst): 208.77.188.166 (наш внешний адрес)

← В обратном направлении (от отвечающего к инициатору):

— Адрес источника (ctreplsrc): 192.168.1.2 (адрес внутреннего сервера)

— Адрес назначения (ctrepldst): 204.152.191.37 (адрес клиента)

В том случае, если адрес-порт назначения при передаче в прямом направлении отличаются от адреса-порта источника при передаче в обратном направлении, соединению будет присвоен статус DNAT.

[!] —ctorigsrcport порт, [!] —ctorigdstport порт, [!] —ctreplsrcport порт, [!] —ctrepldstport порт

Позволяет определять порты источника (src) и назначения (dst) при передаче данных от инициатора к отвечающему (orig) и наоборот (repl) для протоколов транспортного уровня, имеющих порты (TCP, UDP, SCTP, DCCP).

Ситуация с портами в принципе аналогична описанной выше ситуации с адресами, поэтому рассматривать ее отдельно мы не будем.

[!] —ctexpire мин_время[:макс_время]

Позволяет указать в качестве критерия оставшееся по тайм-ауту время в секундах для данного соединения.

Система conntrack присваивает каждому соединению тайм-аут (счетчик обратного отсчета времени). Когда этот счетчик доходит до нуля, система conntrack удаляет информацию о соединении из своих таблиц. Тайм-аут устанавливается в значение по умолчанию каждый раз, когда по соединению передаются данные. Таким образом, активно используемые соединения никогда не будут сброшены.

Заметим, что значения тайм-аута по умолчанию для разных протоколов, и даже для одного протокола на разных стадиях установки соединения, могут различаться. Например, для протокола TCP вводятся отдельные значения тайм-аутов для состояний SYN_SENT, SYN_RECV, ESTABLISHED (не путать TCP-состояние ESTABLISHED с conntrack-состоянием ESTABLISHED), FIN_WAIT, CLOSE_WAIT, LAST_ACK, TIME_WAIT, CLOSE. Для UDP существуют два тайм-аута: для соединений, не получивших статуса ASSURED (conntrack_udp_timeout) и для соединений, по которым передано достаточное количество данных в обе стороны для получения этого статуса (conntrack_udp_timeout_stream). Для ICMP тайм-аут только один.

state

Идеологический предшественник критерия conntrack. Имеет единственный параметр —state, аналогичный параметру —ctstate критерия conntrack (но, в отличие от него, не поддерживающий состояния DNAT и SNAT).

Долгое время был основным критерием определения состояния, и до сих пор фигурирует во многих руководствах и примерах. Однако в настоящее время разработчики iptables рекомендуют использовать вместо него критерий conntrack. Возможно, что критерий state вообще будет удален из будущих версий iptables/netfilter.

Дополнительные критерии

Дополнительные критерии iptables подгружаются при помощи параметра -m (—match). Далее можно указать дополнительные параметры, специфичные для данного конкретного критерия. Если дополнительных критериев несколько, не смешивайте их параметры — указывайте нужные параметры каждого критерия непосредственно после его вызова через -m.

Перед некоторыми дополнительными параметрами критерия может стоять восклицательный знак. В соответствии с принятыми в iptables соглашениями, это означает логическую инверсию параметра, то есть его смысл меняется на противоположный. Но такая возможность предусмотрена отнюдь не для всех параметров.

Заметим, что перечисленные выше критерии состояния и критерии, специфичные для протоколов, по сути также являются параметрами соответствующих дополнительных критериев (например, при указании -p tcp подразумевается еще и -m tcp). Однако в силу ряда причин более логичным и понятным было их отделение от остальных дополнительных критериев. Обратите внимание, что все параметры вышеперечисленных критериев допускают логическое отрицание (например, -m conntrack ! —ctstate NEW).

Справочную информацию по любому из дополнительных критериев можно получить, используя команду

iptables -m название_критерия -h

Вспомогательные критерии

К этой группе можно отнести критерии, расширяющие возможности других критериев.

multiport — позволяет указать несколько (до 15) портов и/или их диапазонов (для протоколов TCP, UDP, SCTP, DCCP и UDP Lite). Поддерживает следующие параметры

[!] —sports, —source-ports порт[:порт][,порт[:порт][,…]] — улучшенная версия критерия —sport, описанного выше. Позволяет перечислить (без пробелов, через запятую) до 15 портов или их диапазонов.

[!] —dports, —destination-ports порт[:порт][,порт[:порт][,…]] — улучшенная версия критерия —dport, описанного выше. Например,

iptables -I INPUT -p tcp -m multiport --dport 80,8000:8008 -j ACCEPT

позволит принимать TCP-пакеты, приходящие на порты 80 и с 8000 по 8008.

[!] —ports порт[:порт][,порт[:порт][,…]] — пакет будет подпадать под этот критерий, если его исходный порт или порт назначения присутствует в указанном списке.

iprange — позволяет указать диапазон IP-адресов, не являющийся подсетью. Поддерживает следующие параметры:

[!] —src-range адрес[-адрес] — позволяет указать диапазон исходных адресов. Например,

iptables -I INPUT -m iprange --src-range 192.168.0.8-192.168.0.25 -j DROP

заблокирует все пакеты, исходный адрес которых лежит в диапазоне с 192.168.0.8 по 192.168.0.25 включительно.

[!] —dst-range адрес[-адрес] — позволяет указать диапазон адресов назначения.

Критерии маркировки

mark — позволяет выделять пакеты с заданной маркировкой (nfmark). Имеет единственную опцию

[!] —mark значение[/маска] — указывает значение маркировки. Простейший пример:

будет выделять пакеты с маркировкой 15.

Если указана маска, то перед сравнением с заданным значением маркировка каждого пакета комбинируется с этой маской посредством логической операции AND, то есть проверяется условие x & маска == значение (где x — маркировка текущего пакета). Такой подход позволит сравнивать значения отдельных бит. Например, критерию

будет отлавливать пакеты, в маркировке которых установлен 7-й бит (<math>2^6=64</math>, при этом первый бит соответствует <math>2^0</math>). В частности, 64…127, 192…255, 320…383 и т. д.

Еще один пример —

будет определять пакеты, в маркировке которых установлен второй бит, но снят первый. Такие числа будут нацело делиться на два, но не делиться на четыре — 2, 6, 10, 14, …

connmark — полностью аналогичен mark, но проверяет не маркировку пакета (nfmark), а маркировку соединения (ctmark). Также имеет параметр —mark с аналогичным синтаксисом.

В качестве практического примера использования меток пакетов и соединений рассмотрим улучшение работы l7-filter-userspace.

Userspace-вариант l7-filter является демоном, взаимодействующим с netfilter через подсистему nfnetlink_queue — действие NFQUEUE в терминологии iptables. При помощи этого действия определенные пакеты можно направить на анализ демону l7-filter. По результатам анализа демон выставит маркировку пакетов: 1 — пакет принадлежит новому соединению, тип которого пока не идентифицирован; 2 — пакет принадлежит соединению, тип которого идентифицировать так и не удалось. Другие значения соответствуют установленным типам соединений (соответствие задается в конфигурационном файле демона) [1].

Задача l7-filter — определить тип протокола прикладного уровня (см. модель OSI) для данного пакета/соединения. Решается эта задача путем анализа содержимого пакета с применением регулярных выражений, позволяющих определить типовые лексемы, характерные для различных протоколов (например, «220 ftp server ready» для FTP или «HTTP/1.1 200 OK» для HTTP). Пакет, в котором встречаются такие лексемы, может быть однозначно классифицирован. В принципе, это дает достаточное основание классифицировать соединение в целом. Однако, в этом поведение kernel и userspace версий l7-filter существенно различается.

Как описывается в документации, версия l7-filter-kernel хранит данные о соединениях и использует их для классификации пакетов, принадлежащих к соединениям, тип которых уже установлен. В то же время, аналогичное утверждение в отношении l7-filter-userspace в документации отсутствует. И, как показывает практика, userspace-версия не использует информацию о соединениях. Возможно, это обусловлено техническими ограничениями nfnetlink_queue как средства взаимодействия l7-filter с системой netfilter.

Описанный недостаток значительно снижает эффективность l7-filter — ведь однозначно классифицированы могут быть всего несколько пакетов из каждого соединения, а всего в соединении могут быть миллионы и миллиарды пакетов. Соответственно, применение l7-filter по своему основному назначению — классификация трафика для последующего шейпинга — не оправдывает себя.

Итак, рассмотрим, как, используя возможности netfilter, можно исправить этот недостаток.

Идея решения проста: после обработки пакетов демоном l7-filter, нужно добавить операции по переносу маркировки пакета на соединение (чтобы классифицировать соединение в целом) и с соединения на пакеты (чтобы пометить уже все пакеты в соединении для дальнейшей обработки шейпером, так как шейпер воспринимает только метки пакетов). Таким образом, классификация одного пакета в соединении влечет классификацию всех последующих пакетов.

Для начала, запустим демон l7-filter-userspace. Небольшое замечание: в его конфигурационном файле (назовем его, например, l7-filter.conf) будем помечать протоколы метками в диапазоне от 16 до 31 включительно (почему — станет понятно из дальнейших пояснений).

l7-filter -f /etc/l7-filter.conf -q 2 -m 0x1f

Параметр -f указывает путь к конфигурационному файлу, -q — номер очереди, -m — задает биты маркировки, модифицируемые демоном l7-filter (в нашем случае — с первого по пятый, что соответствует диапазону значений маркировки от 0 до 31).

Далее, добавим правила, направляющие весь входящий и исходящий трафик (кроме локального) на анализ демону l7-filter:

iptables -t mangle -F # На всякий случай очищаем таблицу mangle
# Направляем на анализ входящий трафик, включая транзитный
iptables -t mangle -A PREROUTING ! -i lo -j NFQUEUE --queue-num 2
# Направляем на анализ исходящий трафик, кроме транзитного
iptables -t mangle -A OUTPUT ! -o lo -j NFQUEUE --queue-num 2

Добавлять второе из этих правил в цепочку POSTROUTING не стоило — ведь в нее попадает как трафик, исходящий от самого хоста, так и транзитный трафик, который уже был обработан ранее, в цепочке PREROUTING. Посмотрев на диаграмму выше, вы можете убедиться, что приведенные правила обрабатывают весь трафик, как принадлежащий самому хосту, так и транзитный, за исключением локального. Локальный трафик (идущий через интерфейс lo), бессмысленно шейпить, а значит, не стоит и классифицировать.

Теперь добавим правила, обеспечивающие копирование маркировки пакетов в маркировку соединений и обратно:

# Для входящего трафика (кроме транзитного)
# Копируем маркировку пакетов в маркировку соединений
iptables -t mangle -A INPUT -m mark --mark 0x10/0xfffffff0 -j CONNMARK --save-mark
# И наоборот
iptables -t mangle -A INPUT -m connmark --mark 0x10/0xfffffff0 -j CONNMARK --restore-mark
# Аналогично для исходящего трафика (включая транзитный)
iptables -t mangle -A POSTROUTING -m mark --mark 0x10/0xfffffff0 -j CONNMARK --save-mark
iptables -t mangle -A POSTROUTING -m connmark --mark 0x10/0xfffffff0 -j CONNMARK --restore-mark

Поясним два момента. Во-первых, добавление этих правил в цепочки PREROUTING и OUTPUT, сразу после правил, передающих трафик демону l7-filter, не имеет смысла — после обработки пакетов демон применяет к ним действие ACCEPT, прекращающее обработку пакета в рамках исходных цепочек. Поэтому мы добавляем эти правила в цепочки, идущие «ниже по течению». Как вы можете заметить по диаграмме выше, такая комбинация правил также обеспечивает обработку всего трафика.

Второй момент, который стоит пояснить — маски специального вида. По сути, они позволяют проверить, лежит ли маркировка пакета в диапазоне от 16 до 31. Такая защита позволяет избежать обработки маркировок 0 (такую маркировку имеет локальный трафик, так как он не проходит процедуру анализа), 1 и 2 (эти значения маркировки, как уже было замечено выше, означают, что тип пакета не определен), а также 32 и выше (эти значения мы оставляем для других задач).

Как показывает практика, даже в самом примитивном случае (детекция протокола HTTP, сервер — nginx 0.6.32, клиент — wbox 4), эффективность детекции возрастает — без использования маркировки соединений регистрируются лишь 2 исходящих пакета (l7-filter работает на сервере), с использованием — 3 исходящих и 2 входящих. Детальное исследование показывает, что детекции избегают лишь первые четыре пакета в соединении — 2 SYN-пакета и 2 пакета с данными. Это цифры, характерные для тестовой задачи — при передаче больших объемов данных количество детектированных пакетов будет значительно больше, в то время как количество не определенных пакетов сохранит тот же порядок.

Более того, предложенный метод решает задачу, не решенную даже в реализации l7-filter-kernel — маркировка связанных соединений. Согласно документации iptables, маркировка соединений автоматически копируется с исходных соединений на связанные с ними (например, с управляющего FTP-соединения на соединение данных).

Примечание: следующий пример планируется к переносу в еще не написанный раздел статьи (Прочие критерии → statistic).

В качестве практического примера использования меток пакетов и соединений можно рассмотреть задачу стохастической балансировки соединений между несколькими аплинками.
Допустим, у нас есть три провайдера, подключенных к интерфейсам eth0, eth1 и eth2 (это могут быть и VLAN-порты одного интерфейса, суть от этого не меняется, только названия), и их шлюзы имеются соответственно IP-адреса 208.77.188.1, 208.77.189.1, 208.77.190.1.

Для начала, создадим для каждого провайдера свою таблицу маршрутизации

echo -e "\n110\tstatic\n111\tprov1\n112\tprov2\n113\tprov3" >> /etc/iproute2/rt_tables

Этот код добавит в конец файла /etc/iproute2/rt_tables строки

 110    static
 111    prov1
 112    prov2
 113    prov3

устанавливающие соответствие между внутренними номерами таблиц маршрутизации и их символьными именами. Используемые здесь имена prov1, prov2 и prov3, разумеется, условны. Таблица static — особая, ее мы рассмотрим чуть ниже.

Обратите внимание, что это действие выполняется только один раз — не надо повторять его при каждой загрузке системы!

Далее, сделаем каждого провайдера шлюзом по умолчанию в «своей» таблице:

ip route add default via 208.77.188.1 dev eth0 table prov1
ip route add default via 208.77.189.1 dev eth1 table prov2
ip route add default via 208.77.190.1 dev eth2 table prov3

Добавим для каждой таблицы правило, отправляющее в нее пакеты с соответствующей маркировкой:

ip rule add fwmark 1 table prov1
ip rule add fwmark 2 table prov2
ip rule add fwmark 3 table prov3
# Но прежде всего пакеты должны пройти таблицу static
ip rule add table static prio 1

Таблица static предназначена для обслуживания статических маршрутов. В частности, в нее мы занесем подсети провайдеров (предположим, что все они класса 1C), а также наши внутренние локальные сети (если таковые есть):

# Провайдеры
ip route add 208.77.188.0/24 dev eth0 table static
ip route add 208.77.189.0/24 dev eth1 table static
ip route add 208.77.190.0/24 dev eth2 table static
# Две наших локалки
ip route add 192.168.1.0/24 dev eth3 table static
ip route add 192.168.2.0/24 dev eth4 table static
# Сбрасываем кеш маршрутов
ip route flush cache

Таким образом, если нашему хосту нужно будет обратиться в подсеть провайдера prov2 (208.77.189.0/24), то маршрут пойдет сразу через интерфейс eth1. Также в этой таблице присутствуют маршруты для наших внутренних локальных сетей — с ними тоже все просто.

По сути дела, таблица static обычно содержит те же маршруты, что и таблица main (главная таблица маршрутизации), за исключением маршрута по умолчанию — таких маршрутов у нас несколько и каждый из них размещается в отдельной таблице, выбор между которыми осуществляется на основании назначенной iptables/netfilter маркировки.

Заметим, что ни в таблицу static, ни в какие-либо другие таблицы не нужно вносить loopback-маршруты, например «127.0.0.1/8 dev lo», так как все эти маршруты фигурируют в автоматически создаваемой таблице local, которую любой пакет проходит в первую очередь (нетрудно убедиться в этом, посмотрев вывод команды «ip rule show»).

Далее, отключим статическую антиспуфинговую фильтрацию:

sysctl net.ipv4.conf.all.rp_filter=0

Reverse path filtering — штука, конечно, удобная и полезная но, к сожалению, совершенно не совместимая с динамической маршрутизацией.

Если вы планируете использовать этот компьютер не только как шлюз, и но и как интернет-сервер (то есть предоставлять доступ к нему извне), необходимо выполнить привязку входящих соединений к их интерфейсам — в противном случае могут возникнуть проблемы, если обращение извне придет через одного провайдера, а сервер ответит через другого.

iptables -t mangle -N bind_connect # Создаем отдельную цепочку (для простоты управления)
# Следите за правильным соответствием значений меток и интерфейсов!
iptables -t mangle -A bind_connect -i eth0 -j CONNMARK --set-mark 1
iptables -t mangle -A bind_connect -i eth1 -j CONNMARK --set-mark 2
iptables -t mangle -A bind_connect -i eth2 -j CONNMARK --set-mark 3
# Пропускаем через эту процедуру все новые соединения к нашему серверу
iptables -t mangle -I INPUT -m conntrack --ctstate NEW -j bind_connect

Теперь, в сочетании с операцией -j CONNMARK —restore-mark, которой мы подвергнем исходящий с нашего сервера трафик (см. ниже), эта процедура обеспечит корректную обработку входящих соединений. (Отметим, что, если бы нам не нужно было бы балансировать исходящие соединения, мы могли бы обойтись вообще без помощи iptables/netfilter, выполнив привязку входящих соединений через правила вида ip rule add from 208.77.188.100 table prov1 и т.п. — ответные пакеты всегда уходят с того же адреса, на который пришел запрос, так что в качестве критерия для выбора шлюза можно использовать исходный адрес.)

Ввиду того, что выбор исходящего адреса для каждого нового соединения осуществляется на основании правил статической маршрутизации (таблица main), могут возникнуть ошибки. Например, если в маршруте по умолчанию (default) в таблице main указан интерфейс eth0, то все исходящие от нас во внешнюю сеть (интернет) соединения будут иметь в качестве исходного адреса первый адрес интерфейса eth0, и ответные пакеты пойдут именно на этот интерфейс. Чтобы избежать возникновения таких ситуаций, добавим маскарадинг для всех исходящих соединений (предполагается, что у всех провайдеров наши внешние адреса имеют вид 208.77.x.100):

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 208.77.188.100
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 208.77.189.100
iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source 208.77.190.100

А теперь — самое интересное. Используя описанный ниже критерий statistic, мы будем случайно распределять метки между пакетами.

iptables -t mangle -N select_prov # Создаем для этого специальную цепочку
iptables -t mangle -A select_prov -j CONNMARK --set-mark 1 # Ставим всем соединениям маркировку 1
iptables -t mangle -A select_prov -m statistic --mode random --probability 0.34 -j RETURN # С вероятностью 34% выходим из этой цепочки
iptables -t mangle -A select_prov -j CONNMARK --set-mark 2 # Ставим всем оставшимся соединениям маркировку 2
iptables -t mangle -A select_prov -m statistic --mode random --probability 0.5 -j RETURN # С вероятностью 50% выходим из этой цепочки
iptables -t mangle -A select_prov -j CONNMARK --set-mark 3 # Всем, кто дошел досюда, ставим маркировку 3

Первое правило в этой цепочке пройдут все пакеты, вошедшие в нее. После этого, 34 % (примерно треть из них) покинет цепочку согласно второму правилу. Далее, оставшиеся пакеты (66 % от первоначального количества) получат маркировку 2. После этого половина из них (то есть 33 % от начального) покинут цепочку с этой маркировкой. Оставшаяся половина (тоже 33 % от начального количества) получат маркировку 3.

После этого, создадим вспомогательную цепочку, осуществляющую маркировку соединений и пакетов:

iptables -t mangle -N sort_connect
iptables -t mangle -A sort_connect -o lo -j RETURN # Локальным соединениям балансировка не нужна
# Аналогично выгоняем пакеты, выходящие через интерфейсы внутренней локалки, если она есть
iptables -t mangle -A sort_connect -o eth3 -j RETURN
iptables -t mangle -A sort_connect -o eth4 -j RETURN
iptables -t mangle -A sort_connect -m conntrack --ctstate NEW -j select_prov # Все новые пакеты прогоняем через процедуру случайного выбора
iptables -t mangle -A sort_connect -j CONNMARK --restore-mark # Копируем маркировку соединений на пакеты

Через цепочку select_prov мы прогоняем только новые пакеты, то есть первые пакеты каждого соединения. После этой процедуры соединение уже имеет маркировку. К сожалению, на данный момент роутинговая подсистема ядра Linux не умеет маршрутизировать пакеты на основании маркировки соединения — только на основании маркировки пакетов. Поэтому действием CONNMARK —restore-mark мы копируем маркировку соединений в маркировку пакетов.

Осталось только добавить вызов этой цепочки в таблицу mangle:

iptables -t mangle -I OUTPUT -j sort_connect

Теперь все ваши исходящие соединения будут балансироваться согласно описанным правилам.

Аналогичную функциональность можно реализовать и для транзитных соединений. Для этого достаточно добавить вызов sort_connect в цепочку FORWARD таблицы mangle:

iptables -t mangle -I FORWARD -j sort_connect

Разумеется, при этом должна быть разрешена передача транзитного трафика, как в таблице filter, так и на уровне sysctl. Как это делается — см. выше.

Заметим, что кроме алгоритма случайной балансировки, критерий statistic позволяет реализовать балансировку в режим round robin. Для этого поменяем цепочку select_prov следующим образом:

iptables -t mangle -F select_prov # Очищаем ее
iptables -t mangle -A select_prov -j CONNMARK --set-mark 1 # Ставим всем соединениям маркировку 1
iptables -t mangle -A select_prov -m statistic --mode nth --every 3 -j RETURN # Первый из трех пакетов - выходим
iptables -t mangle -A select_prov -j CONNMARK --set-mark 2 # Ставим всем оставшимся соединениям маркировку 2
iptables -t mangle -A select_prov -m statistic --mode nth --every 2 -j RETURN # Один из оставшихся двух - выходим
iptables -t mangle -A select_prov -j CONNMARK --set-mark 3 # Последний

Подробнее о принципах работы критерия statistic см. ниже.

В завершение нашего обсуждения стоит заметить, что в некоторых случаях для балансировки соединений достаточно единственной команды

ip route add default scope global nexthop via 208.77.188.1 dev eth0 weight 1 nexthop via 208.77.189.1 dev eth1 weight 1 # И т.д.

Стоит обратить особое внимание на тот факт, что данный метод балансирует пакеты, а не соединения. Например, в том случае, если вы хотите организовать выход в интернет из локальной сети через нескольких провайдеров, не имея единого внешнего адреса, этот метод может работать некорректно — часть пакетов пройдет через одного провайдера и после операции NAT получит один исходный адрес, часть пойдет через другого и соответственно получит другой адрес, и в результате удаленные хосты не смогут правильно обрабатывать соединения, исходящие из вашей сети. Однако, в большинстве случаев этот негативный эффект нивелируется другим фактором — кэшированием маршрутов. При прохождении через такое правило серии пакетов, адресованных некоторому хосту, действительно случайным выбор будет только для первого из них, после чего выбранный маршрут будет закэширован, и остальные пакеты к этому хосту будут маршрутизироваться через тот же шлюз. С одной стороны, подобный эффект позволяет соединениям корректно функционировать, с другой стороны — балансировка оказывается не такой уж и случайной. К тому же, после очистки кэша маршрутов (например, посредством ввода команды ip route flush cached), работа существующих на этот момент соединений может быть нарушена. В качестве наиболее безопасного и целесообразного применения описанного метода можно привести задачу балансировки транзитного трафика в сетях без NAT (условия «прямой видимости» между балансирующим маршрутизатором и точкой схождения потоков трафика). В том случае, если доступ к шлюзам осуществляется через один сетевой интерфейс, этим методом можно балансировать и соединения, исходящие от самого хоста.

Также заметим, что описанные в этом примере методы балансировки не учитывают загруженность каналов. Для этого рекомендуется использовать критерий rateest и действие RATEEST совместно с уже знакомым нам CONNMARK.

Лимитирующие критерии

К этой группе относятся критерии, позволяющие ограничивать количество пакетов, соединений, и переданных байт.

limit — позволяет ограничить количество пакетов в единицу времени. Параметры:

—limit количество[/second|/minute|/hour|/day] — задает ограничение на количество пакетов в секунду (second), минуту (minute), час (hour) или сутки (day). Пакеты в пределах этого количества считаются удовлетворяющими критерию, сверх этого количества — не удовлетворяющими.

—limit-burst количество — задает длину очереди, то есть максимальную пропускную способность.

Критерий -limit использует модель «дырявого ведра», и —limit-burst задает «объем ведра», а —limit — «скорость вытекания». Каждому такому критерию соответствует своя очередь, длина которой задается параметром —limit-burst. Если в очереди есть пакеты, то со скоростью, заданной в —limit, они покидают очередь и считаются удовлетворяющими критерию. Если же вся очередь занята, то новые пакеты в ней не регистрируются и считаются не удовлетворяющими критерию.
Например,

iptables -I INPUT -m limit --limit 3/min --limit-burst 5 -j LOG --log-level DEBUG --log-prefix "INPUT packet: "

предполагает очередь на пять пакетов, которая «продвигается» со скоростью 3 пакета в минуту. При непрерывном поступлении входящих пакетов, очередь всегда будет заполнена, и в лог будут заноситься в среднем по три пакета в минуту. Однако, если входящих пакетов долго не будет, то очередь успеет очиститься, и при поступлении пяти и менее новых пакетов, они пойдут в лог подряд. В любом случае, скорость попадания пакетов в лог остается неизменной.

Типичная ошибка новичков — использовать limit для ограничения TCP-трафика, например, так:

iptables -A INPUT -p tcp --dport 80 -m limit --limit 10000/sec --limit-burst 10000 -j ACCEPT
iptables -P INPUT DROP

Это пример попытки защитить web-сервер от DDoS-атаки, ограничив количество пакетов в единицу времени. Однако, это правило не помешает без особого труда завалить сервер запросами (считая, что на один запрос требуется два входящих пакета — SYN-пакет и пакеты данных, содержащий, например, только GET /, согласно спецификации HTTP 0.9). При этом могут возникнуть помехи для легальных пользователей, например, загружающих на сервер большой файл методом POST. Более корректным решением будет ограничивать не скорость входящего потока данных, а скорость открытия новых соединений:

iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -m limit --limit 32/sec --limit-burst 32 -j ACCEPT
iptables -P INPUT DROP

Теперь мы ограничиваем количество не всех пакетов, а только новых, то есть мы разрешаем открывать не более 32 новых соединений в секунду. Впрочем, число 32 приведено здесь только для примера. Конкретное значение скорости для вашей задачи рекомендуем определять самостоятельно.

hashlimit — позволяет применять ограничения, аналогичные критерию limit, к группам хостов, подсетей или портов, используя всего одно правило. При этом для каждого хоста, подсети или порта создается отдельная очередь. Можно задвать, например, такие критерии:

«1000 пакетов в секунду с каждого хоста из подсети 192.168.0.0/16»

-s 192.168.0.0/16 -m hashlimit --hashlimit-upto 1000/sec --hashlimit-mode srcip

«100 пакетов в секунду с каждого TCP-порта хоста 192.168.1.1»

-s 192.168.1.1 -m hashlimit --hashlimit-upto 100/sec --hashlimit-mode srcport

«10000 пакетов в минуту с каждой подсети префикса 28 (маска 255.255.255.240) из диапазона 10.0.0.0/8»

-s 10.0.0.0/8 -m hashlimit --hashlimit-upto 10000/min --hashlimit-mode srcip --hashlimit-srcmask 28

Обратите внимание, что в каждом из этих правил нужно обязательно указать имя таблицы очередей (haslimit-name, см. ниже), однако, в целях простоты изложения, в некоторых примерах этот параметр опущен.

Рассмотрим основные параметры этого критерия более подробно:

—hashlimit-mode {srcip|srcport|dstip|dstport}[,…] — задает список контролируемых параметров: адреса (ip) и порты (port) источника (src) и назначения (dst). Например, если указать параметр

--hashlimit-mode srcip,dstip

то будет создаваться отдельная очередь для каждой пары «адрес источника — адрес назначения», то есть ограничение будет вводиться на количество пакетов, передаваемых с каждого хоста на другой хост (разумеется, если эти пакеты идут через наш сервер). Или, например,

--hashlimit-mode srcip,srcport

будет создавать отдельную очередь для каждого исходного порта каждого хоста.

—hashlimit-upto количество[/second|/minute|/hour|/day] — этот параметр задает скорость движения очереди (аналог —limit). Если пакеты поступают с такой же или меньшей скоростью, они считаются подпадающими под критерий. Обратите внимание, что этот параметр не поддерживает логической инверсии (отрицания) через восклицательный знак (см. ниже).

—hashlimit-above количество[/second|/minute|/hour|/day] — этот параметр таке задает скорость движения очереди, но смысл его противоположный — если пакеты поступают с большей скоростью, они считаются подпадающими под критерий.

—hashlimit-burst количество — задает длину каждой очереди. Аналогичен —limit-burst.

—hashlimit-srcmask префикс — задает размер подсети исходных адресов, для которой вводится своя очередь. Имеет смысл, только если в haslimit-mode указан режим srcip. Как уже говорилось выше,

-m hashlimit --hashlimit-mode srcip --hashlimit-srcmask 28

будет заводить отдельную очередь для каждой подсети с маской 255.255.255.240 (подробнее про префиксы и маски см. CIDR).
По умолчанию 32 (своя очередь для каждого отдельного хоста). Если указать 0, то контроль по параметру srcip теряет смысл.

—hashlimit-dstmask префикс — задает размер подсети исходных адресов, для которой вводится своя очередь. Имеет смысл, только если в haslimit-mode указан режим dstip. Принцип использования аналогичен hashlimit-srcmask.

—hashlimit-name имя — позволяет использовать несколько независимых таблиц очередей (hashes), распознаваемых по имени. Обязательный параметр. Например,

iptables -F INPUT # Очищаем цепочку INPUT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Пропускаем все, что идет по уже установленным соединениям
# Вводим ограничения для новых подключений по FTP
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 21 -m hashlimit --hashlimit-upto 5/min --hashlimit-mode srcip --hashlimit-name ftphash -j ACCEPT
# Вводим ограничения для новых подключений по rsync.
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 873 -m hashlimit --hashlimit-upto 5/min --hashlimit-mode srcip --hashlimit-name rsynchash -j ACCEPT
iptables -P INPUT DROP # Всех остальных не пускаем

Теперь очереди ограничений для подключения к службам FTP и rsync для нашего сервера будут вводиться независимо, то есть если какой-либо хост превысит предел подключений по FTP, то это никак не повлияет на подключения по rsync. Заметим, что в данном конкретном случае аналогичную функциональность можно реализовать, даже не используя разные хеши:

iptables -F INPUT # Очищаем цепочку INPUT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Пропускаем все, что идет по уже установленным соединениям
# Вводим ограничения для новых подключений по FTP и rsync
iptables -A INPUT -m conntrack --ctstate NEW -p tcp -m multiport --dport 21,873 -m hashlimit --hashlimit-upto 5/min --hashlimit-mode srcip,dstport --hashlimit-name ftprsynchash -j ACCEPT
iptables -P INPUT DROP # Всех остальных не пускаем

Впрочем, выбирая между этими двумя реализациями, стоит учитывать, что размер каждого хеша ограничен.

Не забывайте указывать имя таблицы очередей при каждом использовании критерия hashlimit. Если вы не планируете совместно использовать одни и те же таблицы в нескольких правилах, эти имена должны различаться.

Доступ к таблицам очередей возможен через procfs (файл /proc/net/ipt_hashlimit/имя_таблицы). Подробнее о формате этого файла можно почитать здесь, однако учтите, что большая часть сведений, приведенных в указанной статье, устарела.

Критерий haslimit также имеет ряд параметров, не описанных здесь (максимальный размер таблицы, время жизни записи в таблице, интервал «сбора мусора», и т. п.). За подробными сведениями обратитесь к документации.

connlimit — позволяет ограничивать количество одновременно открытых соединений с каждого IP-адреса (или подсети). Параметры:

[!] —connlimit-above количество — минимальное количество соединений. Все пакеты, проходящие по соединениям, установленным сверх заданного количества, считаются удовлетворяющими критерию. Например,

iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 3 -j DROP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

разрешит не более трех одновременных соединений к нашему веб-серверу с одного IP-адреса. Аналогичного эффекта можно добиться командами

iptables -A INPUT -p tcp --dport 80 -m connlimit ! --connlimit-above 3 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

—connlimit-mask — маска подсети, для которой устанавливается общее ограничение на количество соединений. Например,

iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 5 --connlimit-mask 24 -j DROP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

разрешит не более пяти одновременных соединений на порт 80 с каждой подсети класса 1C.

Не надо путать connlimit с hashlimit — hashlimit позволяет ограничить скорость поступления пакетов с хостов или подсетей (в сочетании с -m conntrack —ctstate NEW — скорость открытия новых соединений), а connlimit — количество одновременно открытых соединений.

connbytes — позволяет ограничивать количество переданных байт или пакетов. Параметры:

[!] —connbytes мин:[макс] — собственно задает количество пакет или байт. Можно указать просто минимальное количество или диапазон.

—connbytes-dir {original|reply|both} — задает направление движения пакетов. Проверяются только пакеты, движущиеся от инициатора соединения к отвечающему (original), наоборот (reply) или в обоих направлениях (both).

—connbytes-mode {packets|bytes|avgpkt} — задает собственно учитываемую величину: количество пакетов (packets), количество байт (bytes) или средний размер пакета (avgpkt).

Пример:

# Для соединений, по которым передано более 500 КБ, ставим минимальный приоритет TOS (требование максимальной полосы)
iptables -t mangle -I INPUT -m connbytes --connbytes 512000: --connbytes-dir both --connbytes-mode bytes -j TOS --set-tos Maximize-Throughput
iptables -t mangle -I OUTPUT -m connbytes --connbytes 512000: --connbytes-dir both --connbytes-mode bytes -j TOS --set-tos Maximize-Throughput
# Для соединений, по которым передано менее 50 КБ, ставим максимальный приоритет TOS (требование минимальной задержки)
iptables -t mangle -I INPUT -m connbytes ! --connbytes 51200: --connbytes-dir both --connbytes-mode bytes -j TOS --set-tos Minimize-Delay
iptables -t mangle -I OUTPUT -m connbytes ! --connbytes 51200: --connbytes-dir both --connbytes-mode bytes -j TOS --set-tos Minimize-Delay

Таким образом, все пакеты, принадлежащие «легким» соединениям, будут маркироваться как наиболее приоритетные, а пакеты, проходящие по «тяжеловесным» соединениям — как наименее приоритетные. Такой подход позволит рационально распределять канал между различными задачами, например, просмотром веб-страниц («легкие» соединения) и скачиванием файлов («тяжелые» соединения).

Конечно, при таком подходе даже «тяжелые» соединения будут занимать канал с наивысшим приоритетом, пока не превысят ограничение. Но даже на медленных соединениях (128 Кбит/с) для этого достаточно всего четырех секунд (если эта закачка в данный момент единственная). После превышения лимита 50 Кбайт соединение получит средний приоритет (TOS не установлен), а еще через некоторое время соединение превысит второй лимит — 500 Кбайт, и получит минимальный приоритет. В то же время, «легкие» соединения в большинстве случаев не превышают даже первого лимита, и поэтому целиком проходят с повышенным приоритетом.

quota — позволяет задать квоту в байтах для данного конкретного правила. Имеет единственный параметр

—quota количество_байт — собственно задает квоту.

Для каждого правила, содержащего такой критерий, создается счетчик, который уменьшается с каждым прошедшим по этому правилу пакетом на количество байт, равное размеру этого пакета. Когда значение счетчика доходит до нуля, правило перестает срабатывать. Чтобы восстановить счетчик, удалите правило и добавьте его снова.

Например:

sysctl net.ipv4.ip_forward=1 # Разрешаем шлюзу передавать транзитный трафик
iptables -F FORWARD # Очищаем цепочку FORWARD
iptables -A FORWARD -m quota --quota 1073741824 -j ACCEPT
iptables -P FORWARD DROP

разрешает хосту передавать не более одного гигабайта транзитного трафика (учитывается трафик в обоих направлениях).

quota2 — критерий из уже упоминавшегося набора xtables-addons. Является результатом развития идей, заложенных в критерии quota. Позволяет создавать именованные счетчики квот (для совместного использования одного счетчика в нескольких правилах), считать не только байты, но и пакеты, а также создавать отдельные правила для пакетов, превышающих квоту (логическая инверсия параметра —quota). Поддерживаются следующие параметры:

—name имя — задает имя счетчика. Текущее значение счетчика содержится в файле /proc/net/xt_quota/имя. Его можно вывести на экран

cat /proc/net/xt_quota/имя

или задать вручную

echo значение > /proc/net/xt_quota/имя

Для осуществления этих действий, как и для работы с iptables, нужны полномочия суперпользователя.

[!] —quota количество — проверяет текущее значение счетчика и уменьшает его на размер текущего пакета. Этот же параметр задает начальное значение счетчика (если счетчик с таким именем уже существует, он не сбрасывается). Пакет считается подпадающим под критерий, если счетчик еще не дошел до нуля (при указании логической инверсии — наоборот). Если немного усложнить наш предыдущий пример,

sysctl net.ipv4.ip_forward=1 # Разрешаем шлюзу передавать транзитный трафик
iptables -F FORWARD # Очищаем цепочку FORWARD
# Устанавливаем квоту для первой подсети
iptables -A FORWARD -s 192.168.1.0/24 -m quota2 --name first --quota 1073741824 -j ACCEPT
# Для тех, кто идет из первой подсети сверх квоты - блокируем и сообщаем об отказе.
# Кстати, счетчик first уже создан, поэтому теперь в параметре quota можно писать любое число. Но мы все-таки напишем 1 Гб.
iptables -A FORWARD -s 192.168.1.0/24 -m quota2 --name first ! --quota 1073741824 -j REJECT
# Устанавливаем квоту для второй подсети
iptables -A FORWARD -s 192.168.2.0/24 -m quota2 --name second --quota 536870912 -j ACCEPT
iptables -P FORWARD DROP

Теперь для подсети 192.168.1.0/24 установлена квота в 1 Гб, и при превышении этой квоты пакеты блокируются, причем их отправителям хост отвечает пакетами icmp-port-unreachable, уведомляя их, что передача данных заблокирована. Для подсети 192.168.2.0/24 устанавливается квота 512 Мб, и при ее превышении никаких сообщений не посылается (пакеты блокируются «молча»). Так же молча блокируются транзитные пакеты из всех остальных подсетей.

—packets — при указании этого параметра счетчик учитывает количество пакетов, а не их суммарный размер.

—grow — увеличивает счетчик, вместо того, чтобы уменьшать его. Критерий с этим параметром всегда возвращает истину. Позволяет создавать счетчики «приходно-расходного типа». Например,

-A INPUT -p tcp --dport 6881 -m quota2 --name bt --grow
-A OUTPUT -p tcp --sport 6881 -m quota2 --name bt

позволяет в любой момент определять разность сумм входящих (на TCP-порт 6881) и исходящих (с этого же порта) байт через файл /proc/net/xt_quota/bt.

Вот еще один пример использования этого критерия для сбора статистики по трафику.

Обратите внимание, что при указании параметра grow критерий quota2 всегда будет возвращать истину. Действие для такого правила обычно назначать не имеет смысла — правило изменяет только счетчик квоты, а не сам пакет.

length — позволяет использовать в качестве критерия размер пакета. Проверятся размер пакета протокола транспортного уровня (TCP, UDP, SCTP, DCCP и т. д.) или, иначе говоря, размер пакета протокола сетевого уровня (IP, IPv6) за вычетом размера заголовков сетевого уровня. Данный критерий имеет единственный параметр

[!] —length размер[:макс_размер], который может употребляться в нескольких формах:

—length размер — пакет проверяется на точное соответствие заданному размеру,

—length мин_размер: — размер пакета должен быть больше или равен заданной величине,

—length :макс_размер — размер пакета должен быть меньше или равен заданной величине,

—length мин_размер:макс_размер — размер пакета должен попадать в указанный диапазон (включая границы).

Смысл всех приведенных форм может быть заменен на противоположный, как обычно, указанием перед данным параметром восклицательного знака. Все размеры задаются в байтах.

В качестве практического примера использования данного критерия можно рассмотреть установку высокого приоритета TOS (требование минимальной задержки) для небольших транзитных пакетов (размер до 512 байт):

iptables -t mangle -I INPUT -m length --length :512 -j TOS --set-tos Minimize-Delay

length2 — расширение критерия length, доступное в наборе xtables-addons. Отличается от классического length возможностью проверять размеры пакетов на различных уровнях модели OSI. Принимает следующие опции:

—layer3 — проверка размера пакета сетевого уровня (например, IPv4-пакета).

—layer4 — проверка размера пакета транспортного уровня (например, TCP-пакета).

—layer5 — проверка размера полезной нагрузки транспортного уровня (например, содержимого TCP-пакета, не учитывая размер заголовков TCP). Работает корректно только для некоторых протоколов транспортного уровня, на момент написания этих строк (конец 2009) поддерживаются: TCP, UDP, UDPLite (en), ICMP, ICMPv6 (en), DCCP, SCTP, IPSec (AH и ESP). Для SCTP-пакета в этот размер включаются все секции (chunks) вместе с их заголовками.

—layer7 — для SCTP проверяется суммарный размер DATA-секций в пакете (то есть его полезная нагрузка), для остальных протоколов аналогично —layer5.

По умолчанию используется —layer3, однако во избежание недоразумений рекомендуется явно указывать одну из перечисленных опций. Если этого не делать, при вводе соответствующей команды появится сообщение

 iptables: length match: Defaulting to --layer3. Consider specifying it explicitly.

Это не является ошибкой (только предупреждением о возможной неоднозначности). Заданное вами правило должно добавиться успешно.

[!] —length размер[:макс_размер] — собственно, задает нужные значения размера. В отличие от аналогичного параметра в классическом критерии length, его синтаксические формы несколько беднее. Допускаются два варианта записи:

—length размер — пакет проверяется на точное соответствие заданному размеру,

—length мин_размер:макс_размер — размер пакета должен быть попадать в указанный диапазон (включая границы).

Впрочем, недостающие варианты легко выразить через имеющиеся: для имитации —length :макс_размер используйте —length 0:макс_размер, а вместо —length мин_размер: применяйте —length мин_размер:65535.

Будьте внимательны: в отличие от length, length2 не проверяет взаимное соответствие границ диапазона (мин_размер <= макс_размер), и если вы зададите их неправильно (мин_размер > макс_размер), ваше правило просто никогда не будет срабатывать.

Подводя краткий итог по разделу «Лимитирующие критерии», хотелось бы заметить, что перечисленные в этом разделе критерии предназначены главным образом для ограничения доступа и защиты от различных атак. Не стоит пытаться ограничивать с их помощью трафик. Для ограничения и приоритезации трафика в Linux рекомендуется использовать стандартный шейпер ядра, управляемый при помощи утилиты tc.

Критерий recent

recent — это специальный критерий, позволяющий запоминать проходящие через него пакеты, а затем использовать полученную информацию для принятия решений. Ввиду его уникальности, широких возможностей и, как следствие, некоторых трудностей в понимании новичками принципов его использования, рассказ о нем был вынесен в отдельный подраздел.

Если быть точным, recent запоминает не сами пакеты, а их количество, время поступления, адрес источника (в последних версиях iptables также может запоминать и адрес назначения), а также, при необходимости, TTL.

В начале кратко рассмотрим его опции:

[!] —set — запомнить адрес источника/назначения пакета (внести его во внутренний список). Если такая запись уже присутствует в списке — обновить время последнего доступа для нее. Обратите внимание, что критерию recent с опцией —set удовлетворяют все пакеты. Чтобы ему не удовлетворял ни один пакет — используйте логическую инверсию (! —set).

[!] —rcheck — позволяет проверить, присутствует ли адрес источника/назначения пакета во внутреннем списке. Критерий recent с этой опцией вернет истину, если адрес в списке присутствует.

[!] —update — работает аналогично —rcheck, но еще и обновляет время последнего доступа для данной записи.

[!] —remove — работает аналогично —rcheck, но еще и удаляет найденную запись из списка. Если запись не найдена, пакет считается не соответствующим критерию.

—seconds число — дополнительная опция в режимах —rcheck и —update. Пакет считается соответствующим критерию, только если последний доступ к записи был не позднее, чем число секунд назад.

—hitcount число — дополнительная опция в режимах —rcheck и —update. Пакет считается удовлетворяющим критерию, если было не менее число обращений к данной записи. Обычно используется вместе с —seconds — тогда критерий имеет смысл «не менее n обращений за последние m секунд».

Заметим, что, хотя в официальной документации для параметров —seconds и —hitcount указывается возможность отрицания (указания перед ними восклицательного знака), на самом деле такое отрицание никак не обрабатывается в коде и не меняет смысла параметров, так что указывать его бессмысленно. Эта ошибка в документации исправлена в версии iptables 1.4.7.

—rttl — дополнительно к адресу источника/назначения, заносить в список и проверять еще и TTL пакета.

—rsource — эта опция появилась в последних версиях iptables, с тех пор, как критерий recent начал поддерживать запоминание адресов не только источника, но и назначения. Позволяет явно указать, что в список вносится именно адрес источника пакета. Однако в целях обратной совместимости этот режим используется по умолчанию, и поэтому указывать данную опцию не обязательно.

—rdest — эта опция появилась в последних версиях iptables. Позволяет явно указать, что в список вносится именно адрес назначения пакета.

—name имя — позволяет указать имя списка при использовании нескольких списков. По умолчанию используется список DEFAULT. Каждый список представлен псевдофайлом /proc/net/xt_recent/имя (на старых ядрах критерий recent реализован только для IPv4, но не для IPv6, поэтому вместо xt_recent будет ipt_recent). В частности, вы можете:

cat /proc/net/xt_recent/имя # вывести список на экран
echo +адрес > /proc/net/xt_recent/имя # добавить адрес в список
echo -адрес > /proc/net/xt_recent/имя # удалить адрес из списка
echo / > /proc/net/xt_recent/имя # очистить список

Теперь давайте рассмотрим несколько примеров.

Блокирование bruteforce-атак (подбор пароля вслепую) на SSH и аналогичные сервисы.

iptables -N ssh_brute_check # Создаем цепочку для проверки попыток соединений на защищаемый порт
# Если за последние 10 минут (600 секунд) с одного адреса было 3 или более новых соединений — блокируем этот адрес
iptables -A ssh_brute_check -m conntrack --ctstate NEW -m recent --update --seconds 600 --hitcount 3 -j DROP
# В противном случае — разрешаем, и при этом заносим в список
iptables -A ssh_brute_check -m recent --set -j ACCEPT
iptables -F INPUT # Очищаем цепочку INPUT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Разрешаем пакеты по установленным соединениям
# Все попытки открыть новое соединение по SSH направляем на проверку
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 22 -j ssh_brute_check
# Здесь можно разрешать те порты, для которых такая проверка не нужна. Например, HTTP
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 80 -j ACCEPT
iptables -P INPUT DROP # Что не разрешено — то запрещено

Теперь все попытки открыть новое SSH-соединение проверяются, и с одного IP-адреса можно открывать не более 2 соединений за 10 минут. Обратите внимание, что за одно соединение злоумышленник может проверить несколько паролей — число попыток аутентификации до обрыва соединения задает параметр MaxAuthTries в файле /etc/ssh/sshd_config. По умолчанию это число равно 6, так что в нашем примере злоумышленник сможет проверять не более 12 паролей за 10 минут.

Впрочем, данный пример весьма тривиален, и сходную функциональность можно получить и при помощи критерия hashlimit:

iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 22 -m hashlimit --hashlimit-mode srcip --hashlimit-upto 5/hour --hashlimit-name ssh -j ACCEPT

разрешит не более 5 новых соединений в час.
Данная реализация имеет недостаток по сравнению с recent — вы не можете произвольно задавать временной период.

Защита от сканирования портов (заметим, что кроме критерия recent для этой задачи можно также использовать критерии psd и lscan из комплекта xtables-addons).

iptables -F INPUT # Очищаем цепочку INPUT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Разрешаем пакеты по установленным соединениям
# Если за последний час было 10 или более запросов на нерабочие порты — блокируем
iptables -A INPUT -m recent --rcheck --seconds 3600 --hitcount 10 --rttl -j RETURN
# Если за последнюю минуту было 2 или более запросов на нерабочие порты — блокируем
iptables -A INPUT -m recent --rcheck --seconds 60 --hitcount 2 --rttl -j RETURN
# Разрешаем рабочие порты
iptables -A INPUT -m conntrack --ctstate NEW -p tcp -m multiport --dport 21,25,53,80,110 -j ACCEPT
iptables -A INPUT -m conntrack --ctstate NEW -p udp -m multiport --dport 53,123 -j ACCEPT
# Всех, кто ломится в нерабочие порты — регистрируем
iptables -A INPUT -m recent --set
iptables -P INPUT DROP # Что не разрешено — то запрещено

Все пакеты, попадающие на нерабочие порты сервера, регистрируются. После нескольких таких попыток за заданный интервал времени адрес их источника блокируется. Проверка TTL добавлена для защиты от блокировки легитимных клиентов после спуфинга злоумышленником от их имени. Хотя, с другой стороны, эта мера позволяет ему обойти защиту от сканирования, выставляя своим пакетам различный TTL. Так что вопрос о нужности этой проверки в вашем конкретном случае вам придется решать самостоятельно.

Другой пример использования критерия recent для детекции и блокирования сканирования портов:

# Создаем цепочку для проверки и блокирования портсканов
iptables -N portscan_check
# Блокируем тех, кто был уличен в портскане в течение последних суток
iptables -A portscan_check -m recent --name portscan --rcheck --seconds 86400 -j DROP
# По прошествии суток можно удалять их из списка
iptables -A portscan_check -m recent --name portscan --remove
# Ну а сейчас — собственно процедура определения портскана
iptables -A portscan_check -p tcp --dport 139 -m recent --name portscan --set -j DROP
# Пускаем на проверку всех, кто пришел к нам из интернета (интерфейс eth0)
iptables -I INPUT -i eth0 -j portscan_check

В данном случае сканированием портов считается обращение на порт 139/tcp (SMB). Впрочем, вы можете задать другой порт или, используя критерий multiport, даже список портов. В отличие от предыдущего примера, здесь производится автоматическая очистка списка IP-адресов: по прошествии суток с момента блокировки, первое же обращение с заблокированного адреса на наш сервер приводит к удалению этого адреса из нашего recent-списка. Однако, если это обращение вновь является попыткой сканирования портов, то есть направлено на порт 139/tcp, адрес тут же блокируется вновь. Именно поэтому процедура блокировки расположена «ниже по течению», чем процедура удаления адреса из списка.

Для предыдущего примера реализация очистки списка адресов достигается следующим образом:

# Создаем цепочку для проверки на необходимость удаления
iptables -N recent_remove
# Последнее обращение на неиспользуемые порты было менее суток назад
# поэтому оставим-ка пока этот адресок в черном списке
iptables -A recent_remove -m recent --rcheck --seconds 86400 -j RETURN
# Если адрес в есть в списке — удаляем его оттуда
iptables -A recent_remove -m recent --remove
# Вставляем эту проверку вторым правилом (сразу после проверки ctstate)
iptables -I INPUT 2 -j recent_remove

Проводя аналогию с ныне почившим проектом PortSentry, первый наш пример соответствует режиму PortSentry «Advanced Stealth Scan Detection», а второй — «Enhanced Stealth Scan Detection». (Правда, заметим, что в режиме Advanced Stealth Scan Detection блокировка производится после первого попадания пакета на нерабочий порт — для достижения такого же эффекта в нашем примере достаточно выкинуть проверки на seconds и hitcount из блокирующих правил.) Однако, использование iptables/recent имеет значительное преимущество перед примитивными userspace-системами наподобие PortSentry — возможность интеграции с системой conntrack, что позволяет избежать ошибочной блокировки, например, при использовании высоких портов для NAT.

Открытие порта «по стуку».

Port knocking — метод защиты портов, при котором доступ к определенному порту с отдельно взятого IP-адреса открывается после серии пакетов на заданную последовательность портов с заданными интервалами. Обычно эта задача решается при помощи демона knockd либо критерия pknock из комплекта xtables-addons.

Несколько самых простых вариантов такой защиты можно организовать и средствами критерия recent.

Самое простое — открывать порт ssh (22) после стука в заданный высокий порт:

iptables -N ssh_knock # Создаем цепочку для проверки попыток соединений на защищаемый порт
# Если за последние 60 секунд было 2 и более стука — блокируем, на всякий случай
iptables -A ssh_knock -m recent --rcheck --seconds 60 --hitcount 2 -j RETURN
# Если за последние 10 секунд стук в нужный порт был — разрешить соединение
iptables -A ssh_knock -m recent --rcheck --seconds 10 -j ACCEPT
iptables -F INPUT # Очищаем цепочку INPUT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Разрешаем пакеты по установленным соединениям
# Все попытки открыть новое соединение по SSH направляем на проверку
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 22 -j ssh_knock
# Здесь мы добавляем правило для регистрации стука
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 27520 -m recent --set
# Опять же на всякий случай — при стуке в соседние порты закрываем SSH
iptables -A INPUT -m conntrack --ctstate NEW -p tcp -m multiport --dport 27519,27521 -m recent --remove
iptables -P INPUT DROP # Что не разрешено — то запрещено

Даже в таком простом примере присутствуют жесткие меры защиты: защищаемый порт (22) открывается на 10 секунд после стука в заданный порт (27520), при этом более одного стука в этот порт в течение минуты считается ошибкой. Также стук в соседние с заданным порты сразу закрывает защищаемый порт. Это делается в целях защиты от подбора стука.

Если вам не интересны такие параноидальные меры безопасности, то обратите внимание на этот простой пример:

iptables -N ssh_knock # Создаем цепочку для проверки
# Если за последние 10 минут было 5 и более попыток соединения — блокируем
iptables -A ssh_knock -m recent --name ssh --update --seconds 600 --hitcount 5 -j RETURN
# Регистрируем
iptables -A ssh_knock -m recent --name ssh --set
# Если за последние 5 секунд было менее двух попыток — блокируем
iptables -A ssh_knock -m recent --name ssh ! --rcheck --seconds 5 --hitcount 2 -j RETURN
# Все остальное — разрешаем
iptables -A ssh_knock -j ACCEPT
iptables -F INPUT # Очищаем цепочку INPUT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Разрешаем пакеты по установленным соединениям
# Все попытки открыть новое соединение по SSH направляем на проверку
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 22 -j ssh_knock
iptables -P INPUT DROP # Что не разрешено — то запрещено

Идея метода проста: защищаемый порт открывается со второй попытки, то есть стук идет непосредственно в него. Вторую попытку нужно сделать в течение 5 секунд после первой. При этом 5 и более попыток за десять минут блокируются (во избежание брутфорса).

Также можно организовать защиту через стук в серию портов:

iptables -N reset_knock # Цепочка для сброса процесса стука
iptables -A reset_knock -m recent --name PHASE1 --remove
iptables -A reset_knock -m recent --name PHASE2 --remove
iptables -A reset_knock -m recent --name PHASE3 --remove
iptables -A reset_knock -m recent --name PHASE4 --remove
iptables -N in_phase_2 # Создаем цепочку для фазы 2
iptables -A in_phase_2 -m recent --name PHASE1 --remove # Удаляем запись из списка первой фазы
iptables -A in_phase_2 -m recent --name PHASE2 --set # Добавляем ее в список второй фазы
iptables -N in_phase_3 # Создаем цепочку для фазы 3
iptables -A in_phase_3 -m recent --name PHASE2 --remove # Удаляем запись из списка второй фазы
iptables -A in_phase_3 -m recent --name PHASE3 --set # Добавляем ее в список третьей фазы
iptables -N in_phase_4 # Создаем цепочку для фазы 4
iptables -A in_phase_4 -m recent --name PHASE3 --remove # Удаляем запись из списка третьей фазы
iptables -A in_phase_4 -m recent --name PHASE4 --set # Добавляем ее в список четвертой фазы
iptables -N checked # Для записей, прошедших проверку
iptables -A checked -j reset_knock # Очищаем списки
iptables -A checked -j ACCEPT # Разрешаем пакет
iptables -F INPUT # Очищаем цепочку INPUT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Разрешаем пакеты по установленным соединениям
# Первая фаза
iptables -A INPUT -p tcp --dport 21210 -m recent --name PHASE1 --set -j RETURN
# Для тех, кто присутствует в списке первой фазы — переход во вторую
iptables -A INPUT -p tcp --dport 11992 -m recent --rcheck --name PHASE1 --seconds 5 -g in_phase_2
# И т.д.
iptables -A INPUT -p tcp --dport 16043 -m recent --rcheck --name PHASE2 --seconds 5 -g in_phase_3
iptables -A INPUT -p tcp --dport 23050 -m recent --rcheck --name PHASE3 --seconds 5 -g in_phase_4
# Если стучатся не в том порядке — сброс
iptables -A INPUT -p tcp -m multiport --dport 21210,11992,16043,23050 -j reset_knock
# Для тех, кто прошел все четыре фазы — разрешаем доступ
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --rcheck --name PHASE4 --seconds 5 -j checked
iptables -P INPUT DROP # Дефолтное правило цепочки INPUT

Принцип прост — при стуке в порт, соответствующий очередной фазе, проверяется наличие записи в предыдущей фазе. Теперь порт 22 откроется на 5 секунд после стука в порты 21210, 11992, 16043, 23050 со строгим соблюдением порядка перечисления и интервалами не более 5 секунд.

Обратите внимание на технику реализации процесса — цепочки фаз вызываются не через -j, а через -g, поэтому после прохождения этих цепочек к пакетам сразу применяется правило по умолчанию цепочки INPUT, то есть DROP. В противном случае пакеты доходили бы до правила сброса (которое с multiport), и процесс стука все время сбрасывался бы.

Последовательный стук в порты можно организовать, например, утилитой netcat

for it in {21210,11992,16043,23050}; do
    echo " " | nc -w 1 host $it
done
ssh user@host

Другие примеры реализации port knocking’а при помощи критерия recent можно посмотреть на OpenNet wiki, debian-administration.org, silverghost.org.ua, форуме OpenNet.

Критерий u32

Данный критерий предоставляет очень гибкий инструмент, позволяющий производить сложные операции по анализу содержимого пакета. Алгоритм обработки содержимого исследуемого пакета задается на специальном языке программирования, своеобразном «ассемблере». Такой подход позволяет получить огромную гибкость, но при этом его изучение и использование может представлять определенные трудности для пользователей, не знакомых с основами программирования и принципами работы машины Тьюринга.

Этот критерий имеет единственный параметр — [!] —u32, после которого в двойных кавычках записывается текст «программы». Если все проверки, заданные в программе, дают истинный результат, пакет считается удовлетворяющим данному критерию. Традиционно, если перед параметром указан восклицательный знак, означающий логическое отрицание, то удовлетворяющими критерию считаются только те пакеты, для которых хотя бы одна проверка дала ложный результат.

Ключевые операторы языка критерия u32:

= — оператор сравнения. Собственно, на его основе и формируются все производимые проверки. Синтаксис его вполне очевиден: выражение = значение. В качестве значения можно использовать одно число, диапазон (в формате мин:макс) или список чисел и/или диапазонов разделенных запятой (например, 1,3:5,8,11:14). В одном списке можно указывать не более 10 чисел/диапазонов.
&& — оператор логического И, объединяющий все производимые в программе проверки. В одном критерии u32 можно указывать не более 10 таких проверок. Обратите внимание, что операция логического ИЛИ отсутствует, так как это противоречит идеологии iptables (в каждом правиле все проверки объединяются логическим И, а логическое ИЛИ объединяет правила в одной цепочке).
& — оператор побитового логического И, позволяющий применить к обрабатываемому значению битовую маску.
<< и >> — операторы побитового сдвига влево и вправо соответственно. Эквивалентны домножению или делению обрабатываемого значения на 2 в соответствующей степени. Обратите внимание, что в одном выражении для проверки можно использовать не более 9 операторов &, << и >>.
@ — оператор задания смещения. Добавляет результат предыдущего выражения к текущему значению начального смещения (в начале работы программы, до выполнения @-операций, начальное смещение считается нулевым). Очень полезен в тех случаях, когда нужно сместиться на некоторое значение, полученное в результате обработки пакета, например, узнав после некоторых вычислений длину IP-заголовка, мы можем сместиться на данные непосредственно после него, т.е. на начало полезной нагрузки IP-пакета (как правило, там находится заголовок транспортного уровня).

Все операторы имеют равный приоритет, исполнение операций всегда происходит слева направо.

Обратите внимание, что программа рассматривает все значения как целые беззнаковые величины, заданные 32 битами, или четырьмя октетами (что соответствует значениям от 0 до 4294967295). Именно поэтому критерий имеет такое название (u32 — unsigned 32-bit).

Другой не вполне очевидный момент — синтаксис операторов =, &, << и >>. Дело в том, что в качестве первого операнда указывается не само значение, а его адрес в пределах пакета, заданный смещением в байтах от текущего начального смещения. Например, 8 = 0x12345678 означает, что нужно взять четыре байта, начиная с восьмого (обратите внимание, что нумерация байтов в пакете начинается нуля), т.е. байты 8, 9, 10 и 11, и сравнить полученное значение с шестнадцатеричным числом 0x12345678. Как уже говорилось, критерий u32 всегда манипулирует блоками по четыре байта, поэтому, если вас интересуют блоки меньшего размера, используйте оператор & и маску, например, 8 & 0xFF = 0x78 позволяет проверить только последний в блоке (11-й от начального смещения) байт. Также можно использовать и оператор смещения, например, 8 >> 24 = 0x12 возьмет первый в блоке (8-й от начального смещения) байт и сравнит его с числом 0x12. Более подробно о битовых операциях можно почитать в соответствующей статье.

Рассмотрим возможности критерия u32 на нескольких простых примерах из официальной документации:

Проверить, превышает ли длина пакета величину 256 байт: —u32 «0 & 0xFFFF = 0x100:0xFFFF».

Эта программа предписывает взять четыре байта, начиная с нулевого, затем занулить первые два байта (в них содержится информация о версии протокола, длине заголовка и типе обслуживания, которая нас сейчас не интересует), и проверить значение, формируемого оставшимися двумя байтами (это и есть полная длина пакета в байтах) на принадлежность диапазону от 0x100 (256 в десятичном счислении) до 0xFFFF (65535, максимально возможная длина пакета).

Проверить, является ли данный пакет ICMP-пакетом с типом 0 (эхо-ответ). Учитывая переменную длину IP-заголовка, эта проверка требует несколько большего количества операций: —u32 «6 & 0xFF = 1 && 4 & 0x3FFF = 0 && 0 >> 22 & 0x3C @ 0 >> 24 = 0»

Рассмотрим эти операции последовательно:

6 & 0xFF = 1 — проверка кода протокола. Код протокола хранится в 9-м (считая с нуля) байте IPv4-заголовка. Чтобы получить это значение, мы берем 4-х байтовый блок с шестого по девятый байт, а затем при помощи маски выделяем последний, интересующий нас байт в это блоке, и сравниваем его с единицей (код протокола ICMP).
4 & 0x3FFF = 0 — проверка, не является ли наш пакет фрагментом. Фрагменты ICMP-пакетов не содержат ICMP-заголовка, в котором должен храниться тип ICMP, поэтому для них дальнейшая проверка не имеет смысла. Пользуясь описанным выше принципом, наша программа выделяет последние 14 бит в блоке с 4-го по 7-й байт, и сравнивает полученное значение с нулем. Строго говоря, для наших целей достаточно было бы и 13 бит (маска 0x1FFF), выделяющих только поле смещения фрагмента (fragment offset, оно должно быть равным нулю для первого пакета в цепочке фрагментов), а использование 14 бит, как это сделано в примере из официальной документации, также захватит и флаг MF (more fragments), что отсечет вообще все фрагментированные пакеты, даже те, которые являются первыми в последовательности и содержат все нужные нам заголовки.
0 >> 22 & 0x3C @ — определение длины IP-заголовка в байтах. Последние четыре бита в первом байте IP-пакета показывают длину IP-заголовка в блоках по четыре байта. Смещая это значение на 22 позиции вправо, мы оставляем справа «зазор» в два бита, которые впоследствии зануляем при помощи маски (3C₁₆ = 111100₂). Также эта маска отсекает лишние биты слева (версия протокола). Полученные два нулевых бита справа соответствуют умножению на четыре, так что в результате мы получаем длину заголовка уже в байтах. Например, если длина IP-заголовка составляет 5 четырехбайтовых блоков (т.е. 20 байт), то изначально первый блок заголовка имеет вид xxxx0101 yyzzzzzz uuuuuuuu uuuuuuuu (где биты xxxx задают версию протокола, 0101₂=5₁₀ — собственно длину заголовка, yyzzzzzz — тип обслуживания, а два байта uuuuuuuu uuuuuuuu показывают полную длину пакета вместе с нагрузкой), то после смещения вправо на 22 бита мы получим в этом блоке следующую картину: 00000000 00000000 000000xx xx0101yy. После применения маски она пример вид 00000000 00000000 00000000 00010100. Полученное число — 10100₂=20₁₀ и будет равно длине заголовка в байтах. Наконец, оператор @ устанавливает полученное значение в качестве начального смещения, поэтому вся дальнейшая адресация ведется уже начиная с начала ICMP-заголовка, который следует непосредственно после IP-заголовка.
0 >> 24 = 0 — выделяет блок с нулевого по третий байт ICMP-заголовка, а затем при помощи смещения (на три байта вправо) оставляет от него только один, нулевой, байт, в котором и хранится тип ICMP. Нас интересует тип 0, поэтому мы и сравниваем этот байт с нулем.

Проверить, задают ли байты с восьмого по одиннадцатый полезной нагрузки TCP-пакета одно из значений: 1, 2, 5, 8. Достигается следующим кодом: —u32 «6 & 0xFF = 6 && 4 & 0x3FFF = 0 && 0 >> 22 & 0x3C @ 12 >> 26 & 0x3C @ 8 = 1,2,5,8»

6 & 0xFF = 6 — выделение байта с кодом протокола и сравнение его с кодом 6 (соответствует TCP). Описание этой проверки уже приведено при рассмотрении предыдущего примера.
4 & 0x3FFF = 0 — проверка, не является ли данный пакет фрагментом. Полностью аналогична описанной в предыдущем примере.
0 >> 22 & 0x3C @ — определение длины IP-заголовка в байтах. Также полностью аналогично описанному в предыдущем примере. После данной операции, начальное смещение указывает на нулевой байт TCP-заголовка.
12 >> 26 & 0x3C @ — определение длины TCP-заголовка в байтах. Принцип действия аналогичен предыдущей операции, с тем лишь отличием, что длина TCP-заголовка закодирована в первых четырех битах двенадцатого байта (а не в последних четырех битах нулевого байта, как в случае с IP-заголовком), поэтому необходимое нам смещение вправо составляет уже 26 бит. Как и в предыдущей операции, мы оставляем справа зазор в два бита, которые впоследствии зануляем маской, и таким образом сразу получаем длину заголовка в байтах. Итак, после второго оператора @, начальное смещение будет указывать на начало полезной нагрузки TCP-пакета (следует непосредственно после заголовка).
8 = 1,2,5,8 — эта операция сравнения вполне тривиальна: выделяется четырехбайтовый блок, начиная с восьмого байта (разумеется, считая от начала полезной нагрузки), и полученное значение сравнивается с одним из допустимых по условию задачи.

Также, в качестве полезных примеров использования критерия u32, можно упомянуть проверку портов источника и назначения в протоколе UDPLite (en): —u32 «6 & 0xFF = 136 && 4 & 0x3FFF = 0 && 0 >> 22 & 0x3C @ 0 >> 16 = исходный_порт» и —u32 «6 & 0xFF = 136 && 4 & 0x3FFF = 0 && 0 >> 22 & 0x3C @ 0 & OxFFFF = порт_назначения» соответственно (после сказанного выше нетрудно догадаться, что исходный порт указывается в первой паре байт UDPLite-заголовка, а порт назначения — во второй, согласно RFC3828).

Прочие критерии

Шаблон:В планах

Критерии из набора xtables-addons

Шаблон:В планах

Программы

Основные

iptables

Работа с цепочками

Работа с правилами

Вывод информации

iptables-save, iptables-restore и iptables-xml

/etc/init.d/iptables

iptables-apply

ipset

ipset работает с типами данных, которые представляют из себя:

ipmap — список IP адресов из определенной подсети
macipmap — связки IP+MAC
portmap — список портов
iphash — произвольный набор IP
nethash — произвольный набор сетей
iptree — временное хранилище IP адресов

Пример правила iptables с применением ipset

iptables -I INPUT 1 -i br0 -p tcp -m set --set test123 src -m tcp --dport 8080 -j ACCEPT

-где test123 это заданное имя сета

ipset -N test123 nethash

Вспомогательные

Полезные при конфигурировании фаервола

Полезные при тестировании фаервола

Фронтенды

С удобным интерфейсом

С графическим интерфейсом

С веб-интерфейсом

Программные интерфейсы

Модули ядра

Модули conntrack и nat

Модули критериев и действий

Параметры sysctl/procfs

Псевдофайлы procfs

Базовые

Относящиеся к критериям и действиям

Основные параметры sysctl

Параметры конфигурации интерфейсов

Параметры, относящиеся к протоколам

TCP

UDP

ICMP

Параметры conntrack

Расширения

Userspace-компоненты

NuFW

l7-filter-userspace

iplist

Наборы дополнительных критериев и действий

Patch-o-Matic

Смотри на официальном сайте http://www.netfilter.org/projects/patch-o-matic/pom-external.html

Patch-o-Matic-NG

xtables-addons

Команды

Программа позволяет задать правила, которым должны соответствовать проходящие через брандмауэр IP-пакеты. Эти правила, как и все настройки Linux, записываются в текстовый файл, находящийся в папке /etc. Последовательность правил называется цепочкой (CHAIN). Для одного и того же сетевого интерфейса используются несколько цепочек. Если проходящий пакет не соответствует ни одному из правил, то выполняется действие по умолчанию.

При вызове, параметром указывается команда, которую нужно выполнить. Обычно можно указать только одну команду (но есть исключения). Команду можно указать одной большой буквой или словом. Если при вызове любой команды не указано название таблицы, то команда выполняется в таблице filter. Программа имеет подробную справку, вызываемую командой man iptables.

Вывести правила (-L, —list)

iptables [-t таблица] -L [цепочка] [параметры]

Вывести список правил для указанной таблицы и цепочки. Если цепочка не указана, то выводятся список правил для каждой цепочки. Например для вывода правил из таблицы nat:
iptables -t nat -n -L

Часто используются параметры -n (во избежение медленных запросов DNS) и -v (для вывода более подробной информации).

Команду -L можно использовать с -Z (iptables -L -Z) для вывода значений счетчиков и одновременного их обнуления.

Удалить все правила из цепи (-F, —flush)

iptables [-t таблица] -[F] [цепочка] [параметры]

Если цепочка не указана, то удаляются все цепочки из таблицы.

Обнулить все счетчики (-Z, —zero)

iptables [-t таблица] -Z [цепочка] [параметры]

Присваивает счетчикам числа пакетов и объема данных нулевые значения. Если цепочка не указана, то обнуление выполняется для всех цепочек.

Команду -Z можно использовать с -L (iptables -L -Z) для вывода значений счетчиков и одновременного их обнуления.

Создать новую цепочку (-N, —new-chain)

iptables [-t таблица] -N цепочка

Создать новую цепочку в указанной таблице с указанным именем. Если в указанной таблице уже есть цепочка с указанным именем, то новая не создается.

Удалить созданную цепочку (-X, —delete-chain)

iptables [-t таблица] -X [цепочка]

Удалить цепочку ранее созданную с помощью команды -N. Перед удалением цепи необходимо удалить или заменить все правила, которые ссылаются на эту цепочку. Если цепочка не указана, то из таблицы будут удалены все цепи кроме стандартных (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING). Стандартные цепочки не удаляются.

Переименование цепи (-E, —rename-chain)

iptables [-t таблица] -E цепочка новое_название

Присваивает указанной цепочке новое название. Косметическая функция, не влияющая на функциональность.

Установить политику для стандартной цепи (-P, —policy)

iptables [-t таблица] -P цепочка действие [параметры]

Над пакетами которые доходят до конца указанной цепочки будет выполняться указанное действие. В качестве действия нельзя указывать название какой-либо цепочки. Устанавливать политику можно только на встроенных цепочках. Например:
iptables -P INPUT DROP

Команды модификации правил

Добавить новое правило (-A, —append chain)

iptables [-t таблица] -A цепочка спецификация_правила [параметры]

Правило добавляется в конец указанной цепочки. Если в спецификации правила указано имя отправителя или получателя, которое одновременно соответствует нескольким адресам, то в конец цепочки добавляются правила для всех возможных комбинаций.

Вставить новое правило (-I, —insert)

iptables [-t таблица] -I цепочка [номер_правила] спецификация_правила [параметры]

Указанное правило вставляется в указанное место указанной цепочки. Правила нумеруются с 1, поэтому если указать номер 1 (или не указать вообще), то правило будет вставлено в начало цепочки.

Удалить правило (-D, —delete)

iptables [-t таблица] -D цепочка номер_правила [параметры]

iptables [-t таблица] -D цепочка спецификация_правила [параметры]

Правило можно указывать при помощи его номера в цепочке (нумерация начинается с 1) или его спецификации.

Заменить правило (-R, —replace)

iptables [-t таблица] -R цепочка номер_правила спецификация_правила [параметры]

Заменить правило с указанным номером в указанной цепочке. Правила нумеруются с 1. Спецификация правила не может содержать имени отправителя или получателя, которое одновременно соответствует нескольким адресам.

Параметры определения правил

Важно.
В последующих версиях описанный ниже синтаксис изменился. Например, старому синтаксису

-s, —src, —source [!] адрес[/маска]

теперь соответствует новый

[!] -s, —src, —source адрес[/маска]

Перечисленные ниже параметры используются при задании спецификации правил и указываются с командами модификации правил. Эти параметры ограничивают применение правил — если обрабатываемый пакет не соответствует указанным в спецификации критериям, то указанное в правиле действие на этот пакет не распространяется.

-p, —protocol [!] протокол

Ограничение протокола. Основные значения: tcp, udp, icmp, или all. Протокол также можно указать с помощью номера, или названия указанного в файле /etc/protocols. Знак «!» перед именем протокола изменяет критерий на противоположенный (например !tcp означает «любой протокол, кроме TCP»). Значение «Любой протокол» можно указать с помощью слова all или числа 0. Если протокол не указан, то подразумевается «Любой протокол».

-s, —src, —source [!] адрес[/маска]

Ограничение отправителя. Адрес может быть IP-адресом (возможно с маской), именем хоста, или доменным именем. Маска может быть в стандартном формате (например 255.255.255.0) или же в виде числа, указывающего число единиц с «левой стороны» маски (например 24). Знак «!» перед адресом изменяет критерий на противоположенный.

Настоятельно не рекомендуется использовать имена, для разрешения которых требуется удаленный запрос, например по системе DNS.

-d, —dst, —destination [!] address[/mask]

Ограничение получателя. Синтаксис такой же, как у —src.

-i, —in-interface [!] имя_интерфейса

Ограничение входящего сетевого интерфейса. Знак «!» перед адресом изменяет критерий на противоположенный. Если указанное имя интерфейса заканчивается на «+», то критерию совпадают все интерфейсы, чьи имена начинаются на указанное имя. Если параметр —in-interface не указан, то критерию соответствуют пакеты из любого сетевого интерфейса.

-o, —out-interface [!] имя_интерфейса

Ограничение выходящего сетевого интерфейса. Синтаксис такой же, как и для —in-interface.

[!] -f, —fragment

Ограничение пр фрагментам: критерию соответствуют только фрагменты пакета, начиная со второго фрагмента. Знак «!» перед адресом изменяет критерий на противоположенный.

У таких фрагментов начиная со второго нет заголовка с портами отправителя и получателя (или с типом ICMP). Следовательно, такие фрагменты не соответствуют критериям, указывающим номера портов.

-j, —jump действие_или_цепочка
-g, —goto цепочка

Спецификация действий и переходов. Если указанно название цепочки ранее созданной командой -N, то пакеты соответствующие критериям правила переносится в начало указанной цепочки (запрещено указывать название цепочки, в котором это правило находится). Если указано действие, то оно выполняется над пакетами соответствующим критериям правила. Если в правиле нет параметров —jump и —goto, то правило не влияет на проверяемые пакеты (но счетчик правила продолжает работать).

—goto отличается от —jump поведением при действии RETURN. Действие RETURN переводит пакет в правило, следующее после того, которое вызвало предыдущий переход —jump. То есть, если пакет перешел из цепочки X в цепочку Y при помощи —jump, а потом в Z опять при помощи —jump, то действие RETURN из цепочки Z возвращает его в Y. Если же пакет перешел в Z при помощи —goto, то RETURN возвращает его в X.

-c, —set-counters пакеты байты

Параметр позволяет при добавлении или изменении правил одновременно инициализировать счетчики числа пакетов и размера данных.
_{Подстрочный текст}

Модули

Кроме фильтров по умолчанию поддерживаются дополнительные модули, подключающиеся автоматически при выборе протокола (-p) или вручную опцией -m (—match), после которой следует имя подключаемого фильтра и его опции. Также как и для остальных правил фильтрации, здесь можно использовать ! в качестве отрицания.

Некоторые из встроенных (входящие в стандартный пакет)

state

Соединением для NetFilter является закономерно оформленная последовательность обмена пакетами между хостами, с выделением роли каждого пакета в соединении. Эта особенность позволяет контролировать трафик с точки зрения транспортного уровня (модели OSI). Ядро NetFilter отслеживает соединения и ведёт активное наблюдение за открытием новых, протеканием и завершением установленных соединений. Каждый пакет может быть классифицирован по одному из следующих состояний: NEW, ESTABLISHED, RELATED и INVALID.

NEW — типов пакетов, участвующих в установке нового соединения.

ESTABLISHED — пакет уже установленного соединения

RELATED — Соединение получает статус RELATED если оно связано с другим соединением, имеющим признак ESTABLISHED. Это означает, что соединение получает признак RELATED тогда, когда оно инициировано из уже установленного соединения, имеющего признак ESTABLISHED.

Состояние RELATED относится к служебному трафику, протоколу ICMP стека TCP/IP.

INVALID — неправильный/ошибочный/испорченный пакет. Обычно для таких пакетов применяют действие DROP

ПРИМЕР:

iptables -t nat -A PREROUTING -s 10.10.10.10 -m conntrack --ctstate NEW,INVALID -j DROP

Все новые и ошибочные пакеты, идущие с адреса 10.10.10.10 отбрасываются

connlimit

Позволяет задавать возможное количество одновременных подключений к машине от заданного IP или блока адресов

[!] —connlimit-above n — пакет подойдет под описание, если количество одновременных подключений на данный момент больше (меньше), чем n

—connlimit-mask bits — позволяет задать маску блока адресов

iprange

Выделяет не один адрес, как —src, а все адреса от ip1 до ip2

Нужно учитывать тот факт что перед использованием данного критерия, необходимо подгрузить модуль его реализующий «-m iprange»

[!]—src-range ip1-ip2

[!]—dst-range ip1-ip2

multiport

Выделяет не один порт, как —dport или —sport, а несколько по списку (до 15 штук). Можно задавать диапазоны как первый_порт:последний_порт. Может быть использовано только вместе с -p udp или -p tcp.

[!]—source-ports port1,port2,port3:port4

[!]—destination-ports port1,port2,port3:port4

[!]—ports port1,port2,port3:port4

mac

Сравнение не IP источника пакета, а его ethernet-адреса

[!] —mac-source address. MAC-адрес должен быть указан в стандартном формате XX:XX:XX:XX:XX:XX.

Если нужна фильтрация по MAC-адресу в мостовых соединениях (например, pppoe), то можно воспользоваться утилитой ebtables, которая предназначена как раз для более низкоуровневой фильтрации пакетов.

Примечания

Шаблон:Примечания

Литература

Шаблон:Книга

Ссылки

Настройка межсетевого экрана в Linux

Сайт проекта Netfilter
Man page of iptables Шаблон:Ref-en
Руководство по iptables (Iptables Tutorial 1.1.19)*Шаблон:Ref-ru
Простой полноценный межсетевой экран (готовый шаблон для дектопа) Шаблон:Ref-en
Настройка межсетевого экрана Iptables (готовый шаблон для дектопа)*Шаблон:Ref-ru
flex-fw — это гибкая надстройка над iptables для построения сервис-ориентированного statefull-фаервола с простым синтаксисом команд
linux.die.net/man/8/iptables Шаблон:Ref-en
‘man iptables’ /*ubuntu linux*/Шаблон:Ref-en (ubuntu community)Шаблон:Ref-en
‘man ufw’ /*ubuntu linux*/Шаблон:Ref-en (ubuntu community)Шаблон:Ref-en
‘man gufw’ /*ubuntu linux*/Шаблон:Ref-en (ubuntu community)Шаблон:Ref-en
‘ubuntu fierwall’- ‘ufw utility’ (ubuntu community) Шаблон:Ref-en

↑ Разработчики Netfilter представили замену iptables
↑ Если кратко, EtherType указывает тип протокола, инкапсулированного в Ethernet-кадр. При работе с iptables это значение будет всегда равно 08:00 (протокол IPv4), при работе с ip6tables — 86:DD (IPv6). Полный список EtherTypes доступен на сайте IANA, список поддерживаемых netfilter’ом — в файле /etc/ethertypes, который в большинстве дистрибутивов находится в пакете ebtables.
↑ Обычно проблемы с пониженным MTU в Ethernet-сетях возникают как раз из-за VPN-туннелей
↑ На самом деле, для «чистого» проброса адреса, даже при использовании stateful NAT, необходимо обычно два или три правила, в частности, для проброса соединений с самого сервера в цепочке OUTPUT. Более подробно это описано при рассмотрении операции DNAT таблицы nat, и здесь, с целью упрощения понимания примера, эти аспекты опущены
↑ Заметим, что для расчета масок подсетей и диапазонов адресов существует очень удобная утилита ipcalc.

Источник

�������: ������ �������

����������

�� ������

��� ������ ���� ��������

��������������� �������

������������ ����������

����� 1. ��������

1.1. ������ ���� �������� ������ �����������

1.2. ��� �� ��� �������

1.3. �������, ������������ � ������ ���������

����� 2. ����������

2.1. ��� ����� iptables

2.2. ��������� ����

2.3. ��������� ������

2.3.1. ������ ������

2.3.2. ��������� � Red Hat 7.1

����� 3. ������� ����������� ������ � �������

3.1. ����� ���������

3.2. ������� Mangle

3.3. ������� Nat

3.4. ������� Filter

����� 4. �������� ����������� ���������

4.1. ��������

4.2. ������� �������������

4.3. ��������� � ������������ ������������

4.4. TCP ����������

4.5. UDP ����������

4.6. ICMP ����������

4.7. ��������� ��-���������

4.8. ����������� ����������� ����������

����� 5. ���������� � �������������� ������� ������� ������

5.1. �����

5.2. � ������

5.3. iptables-save

5.4. iptables-restore

����� 6. ��� ������� �������

6.1. ������

6.2. �������

6.3. �������

6.4. ��������

6.4.1. ����� ��������

6.4.2. ������� ��������

6.4.2.1. TCP ��������

6.4.2.2. UDP ��������

6.4.2.3. ICMP ��������

6.4.3. ����� ��������

6.4.3.1. �������� Limit

6.4.3.2. �������� MAC

6.4.3.3. �������� Mark

6.4.3.4. �������� Multiport

6.4.3.5. �������� Owner

6.4.3.6. �������� State

6.4.3.7. �������� TOS

6.4.3.8. �������� TTL

6.4.4. �������� «������» (Unclean match)

6.5. �������� � ��������

6.5.1. �������� ACCEPT

6.5.2. �������� DNAT

6.5.3. �������� DROP

6.5.4. �������� LOG

6.5.5. �������� MARK

6.5.6. �������� MASQUERADE

6.5.7. �������� MIRROR

6.5.8. �������� QUEUE

6.5.9. �������� REDIRECT

6.5.10. �������� REJECT

6.5.11. �������� RETURN

6.5.12. �������� SNAT

6.5.13. �������� TOS

6.5.14. �������� TTL

6.5.15. �������� ULOG

����� 7. ���� rc.firewall

7.1. ������ rc.firewall

7.2. �������� �������� rc.firewall

7.2.1. ������������

7.2.2. �������� �������������� �������

7.2.3. ��������� /proc

7.2.4. ���������� ������ �� ������ ��������

7.2.5. ��������� ������� ��-���������

7.2.6. �������� ���������������� ������� � ������� filter

��: ��

��

��

��

��

��

�� 1. ��

1.1. ��
��

1.2. ��

1.3. ��, ��
��

�� 2. ��

2.1. �� iptables

2.2. ��

2.3. ��

2.3.1. ��

2.3.2. �� Red Hat 7.1

�� 3. ��
� ��

3.1. ��

3.2. �� Mangle

3.3. �� Nat

3.4. �� Filter

�� 4. ��
��

4.1. ��

4.2. ��
��

4.3. ��
��

4.4. TCP ��

4.5. UDP ��

4.6. ICMP ��

4.7. ��
��-��

4.8. ��
��

�� 5. ��
��

5.1. ��

5.2. � ��

�� 6. ��

6.1. ��

6.2. ��

6.3. ��

6.4. ��

6.4.1. ��

6.4.2. ��

6.4.2.1. TCP ��

6.4.2.2. UDP ��

6.4.2.3. ICMP ��

6.4.3. ��

6.4.3.1. �� Limit

6.4.3.2. �� MAC

6.4.3.3. �� Mark

6.4.3.4. ��
Multiport

6.4.3.5. �� Owner

6.4.3.6. �� State

6.4.3.7. �� TOS

6.4.3.8. �� TTL

6.4.4. �� «��»
(Unclean match)

6.5. ��

6.5.1. �� ACCEPT

6.5.2. �� DNAT

6.5.3. �� DROP

6.5.4. �� LOG

6.5.5. �� MARK

6.5.6. ��
MASQUERADE

6.5.7. �� MIRROR

6.5.8. �� QUEUE

6.5.9. �� REDIRECT

6.5.10. �� REJECT

6.5.11. �� RETURN

6.5.12. �� SNAT

6.5.13. �� TOS

6.5.14. �� TTL

6.5.15. �� ULOG

�� 7. �� rc.firewall

7.1. �� rc.firewall

7.2. ��
rc.firewall

7.2.1. ��

7.2.2. ��
��

7.2.3. �� /proc

7.2.4. ��
��

7.2.5. ��
��-��

7.2.6. ��
�� filter

7.2.6.1. ��
bad_tcp_packets

7.2.6.2. �� allowed