Linux networking notes


netfilter/iptables

To list the NAT table:


iptables -L -t nat

Flushing iptables:

iptables -X doesn't flush all the tables.

To flush all the tables:

iptables -X
iptables -t nat    -F PREROUTING
iptables -t nat    -F POSTROUTING
iptables -t mangle -F PREROUTING
iptables -t mangle -F POSTROUTING

Port forwarding:

Netfilter's port forwarding capability allows external access from the outside Internet to an internal host behind the firewall.

The following command, when run on a Linux gateway, will allow external access to the web server running on the host at 10.0.0.100 (in the internal network). To prevent conflict, the gateway should not be running a web server.

iptables -t nat -A PREROUTING -i ppp+ -p tcp --dport http -j DNAT --to 10.0.0.100

Traffic shaping, prioritizing bandwidth:

Netfilter can be used for "traffic shaping" (as can QoS support in the Linux kernel).
The following excerpt is from Prioritizing interactive traffic.
It shows how to prioritize bandwidth by port using netfilter/iptables:

--- BEGIN QUOTE ---
The most common use is to set telnet & ftp control connections to "Minimum Delay"
and FTP data to "Maximum Throughput".
This would be done as follows, on your upstream router:

# iptables -A PREROUTING -t mangle -p tcp --sport telnet \
  -j TOS --set-tos Minimize-Delay
# iptables -A PREROUTING -t mangle -p tcp --sport ftp \
  -j TOS --set-tos Minimize-Delay
# iptables -A PREROUTING -t mangle -p tcp --sport ftp-data \
  -j TOS --set-tos Maximize-Throughput
--- END QUOTE ---

Warning about inserting rules into firewall scripts:

Many people are blindly inserting these 3 example rules from the Netfilter docs into their own custom firewall scripts:

# Syn-flood protection:
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

# Furtive port scanner:
ptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

# Ping of death:
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

I see these problems:

1. The "ping of death" rule is really a "ping flood" rule.
Rather, a "ping of death" is a silver bullet: a single packet with an oversized payload.
BTW, modern Linux kernels (>2.4) are immune to ping-of-death.

2. The Linux kernel's CONFIG_SYN_COOKIES provides better SYN-flood protection, which can be enabled by:
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

3. Most importantly, if a packet is not from a SYN-flood attack, but is a packet
from a port scanner or ping flood attack, it WILL BE ACCEPTED by the first rule, won't it?


© 2002,2004 Jim Brooks home
Last modified: Wed Aug 25 14:14:30 EDT 2004