Syntax and Use of IPTables
A comprehensive documentation of IPTables/NetFilter is available online (see references below) and
additional documentation can be found in the IPTables man pages.
IPTables has the following options to manage whole chains:
-N — Create a new chain.
-X — Delete an empty chain.
-P — Change the policy for a built-in chain.
-L — List the rules in a chain.
-F — Flush the rules out of a chain.
-Z — Zero the packet and byte counters.
The following are ways to manipulate rules inside the chain:
-A — Append a new rule.
-I — Insert a new rule.
-R — Replace a rule.
-D — Delete a rule.
A simple script with comments written by Oskar Andreasson of BoingWorld.com is shown in Listing 1.
The script shows the implementation of some simple IP forwarding, masquerading (NAT) spoofing checks
of non-routable addresses (RFC191, and the opening of some ports to allow access. If you are
familiar with ipchains, you will probably have little difficulty in following most of the rules.
The command:
iptables -P <chain name> <policy>
sets the default policy for the chain, either ACCEPT or DROP (DENY). Only built-in chains (INPUT,
OUTPUT, and FORWARD) have policies. Packet-mangling activities that modify the packets in transit
(such as NAT and proxying) use two additional predefined chains, PREROUTE (usually for DNAT), and
POSTROUTE (usually for SNAT). The names are descriptive enough and convey the fact that DNAT
destination addresses are typically rewritten before other chain rules are applied, and SNAT source
addresses are rewritten after they have traversed the rule chains.
Rules are added to chains using the following syntax:
iptables -A <chain name> <match condition> -j <jump>
>The condition is a logical match of, for example, the following:
-s <source IP>
-d <destination IP>
-sport <source port>
-dport <destination port>
-p <protocol tcp, udp, or icmp>
-m <match, e.g., MAC address or TCP state>
-owner <user/group/process/session id>
The above match conditions are meant to be extensible, and numerous other extensions exist. To learn
more about a match extension, use the -h option. For example, for the ICMP protocol (-p), type:
#/sbin/iptables -p icmp -h
and a list of the three dozen or so -icmp-type extensions will be displayed.
The jump (or “judgement”) following the -j is one of the following:
ACCEPT — Accept the packet.
DROP — Drop the packet.
REJECT — Drop the packet and respond with “port-unreachable” ICMP packet.
NAT — Rewrite the packets source or destination address.
LOG — Log to the kernel logging daemon klogd.
TOS — Impose a type/level of service.
Example Applications of Some Rules
Here are some example rulesets for the features described in the “Enhancements” section:
1. Stateful Inspection — The rule:
/sbin/iptables -A FORWARD -m state --state \
ESTABLISHED,RELATED -j ACCEPT
forwards packets across the firewall that are part of a pre-existing connection. Besides ESTABLISHED
(packet is part of existing connection) and RELATED (packet is related to existing connection and
passing in same direction), other defined states are NEW (packet is trying to create a new
connection), INVALID (packet doesn’t match any exisitng connection), and RELATED+REPLY (packet is
not part of an existing connection, but is related to one (e.g., ftp-data transfer requested
following an existing ftp-control session).
2. DNAT — To redirect traffic from the 10.0.0.0 network to the Web server 10.0.1.1 to the Web server
10.0.1.100, use the rule:
# /sbin/iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -d \
10.0.1.1 -p tcp --dport 80 -j DNAT --to 10.0.1.100
You can implement a load-balancing solution and redirect all incoming traffic to port 8080 on a
group of servers IP 10.0.1.100-10.0.1.102:
# /sbin/iptables -t nat -A POSTROUTING -p -s 10.0.0.0/24 \
-d 10.0.1.1 tcp -dport 80 -j DNAT --to 10.0.1.100-10.0.1.102:8080
3. Enhanced TCP monitoring — To check all six TCP flags and check that the SYN and ACK flags are
set:
#/sbin/ iptables -A INPUT -p tcp --tcp-flags ALL SYN,ACK -j DROP
To deny outgoing connections to insecure telnet, FTP, and rsh services using a single command:
# /sbin/iptables -A input -t DENY -p tcp --destport telnet,ftp,shell
Note that in ipchains, each port would have required its own separate rule.
4. Filtering by MAC address — The rule:
# /sbin/iptables -A FORWARD -m state --state \
NEW -m mac --mac-source 00:C7:8F:72:14 -j ACCEPT
allows only outgoing packets from a known MAC address, given in colon-separated hex notation.
5. Enhanced logging:
# /sbin/iptables -A INPUT -s 192.168.0.1 -m limit -limit \
1/second -j LOG
limits the rate of writes to the logs to one per second. Specific matches can be labeled. For
example, log entries corresponding to connect requests from the Litigation Department’s Cisco 1601
router can be labeled:
# /sbin/iptables -A INPUT -s 192.168.5.254 \
-j LOG --log-prefix ' ## Litigation Dept Cisco 1601 ## '
The logfile entry looks like:
Aug 1 14:58:39 mymachine kernel: ## Litigation Dept Cisco 1601 \
## IN=eth0 OUT= MAC=00:f0:28:2c:69:67:00:00:7a:93:5e:62:08:00 \
SRC=192.168.5.254 DST=192.168.1.254 LEN=40 TOS=0x00 PREC=0x00 \
TTL=247 ID=21864 DF PROTO=TCP SPT=42300 DPT=23 WINDOW=8760 RES=0x0
0 RST URGP=0
6. Rate-Limited matching — To protect from syn-flood denial of service, only accept a maximum of 1
per second:
#/sbin/iptables -A FORWARD -p tcp -syn -m limit -limit 1/s -j ACCEPT
7. Type of Service (TOS) prioritization — To maximize ssh response while maintaining maximum file
data transfer over HTTP connections, the following rule can be applied:
# /sbin/iptables -A PREROUTING -t mangle -p tcp --sport ssh \
-j TOS --set-tos Minimize-Delay
# /sbin/iptables -A PREROUTING -t mangle -p tcp --sport http \
-j TOS --set-tos Maximize-Throughput
Conclusion
This article explains some new firewalling features of IPTables that administrators of
ipchains-based Linux firewalls may find useful. My aim was also to provide a starting point for
administrators who are familiar with ipchains based-firewalling and are considering a move to
IPTables/NetFilter. Much of the hoopla surrounding the Linux 2.4 kernel has revolved around IPTables
support for stateful packet inspection. However, I hope that this article has shown that there is
more to IPTables than merely stateful inspection. IPTables also can provide firewalling scripts that
are cleaner and easier to read, and easier to maintain. It seems that with its many powerful new
features, Open Source Linux firewalling has finally come of age.
แสดงกระทู้
